How about just completely disabling PostgreSQL on HHVM since it basically looks like there isn't feature parity between the PHP and HHVM implementations? It probably means adding a check for HHVM in JDatabaseDriverPostgresql::isSupported(); and calling that method in the test cases testing PostgreSQL code using an un-mocked database driver.

It looks like there are about 24 missing functions when compared to the Zend pgsql module and 2 new functions that are not in the Zend module.

So far from what I can tell there are really just the two issues with our pgsql driver. Both of which we could check for the function existence to work around them. (which is what I did for my testing here for pg_set_error_verbosity() and here for pg_set_client_encoding()

I think fixing the setUtf() fix for for pg_set_client_encoding() is a good solution that a PR could be opened with (or added to this PR).

As for the connect() fix for pg_set_error_verbosity() I think it's ok, but there might be a better work around for that issue.

Whether we fix the couple of items in the pgsql driver or exclude it from testing would still be an improvement. Note: Some hhvm versions like 3.13 do not have a pgsql extension which can limit which versions we can test against.

In either case, now that hhvm can be targeted to LTS versions for testing we should make the change to test against LTS version rather than the incremental latest version that we are currently using.

Since HHVM is still in testing and unofficially supported, come July/August we'll need to decide about 3.15 which is the next expected LTS (do we add to our testing list like PHP or do we increment to the next LTS pending official project support, or do we change to hhvm-nightly in the mean time)

I'll look at reopening this with the Changes needed due to the merge from the JS unit tests. Reopening is Pending PHPunit continuing support of HHVM or an HHVM specific unit testing option being available.