@photodude Can you double check the AppVeyor config here? I'm trying to conditionally add the deprecated ext/mysql for the PHP 5.6 build but it doesn't seem to be registering right (all of the tests for that driver are failing with a "can't connect" message, MySQLi and PDO MySQL are fine).

Got it sorted, just had to change syntax. So there are 5 Windows versus Linux errors in the tests/code to sort out then the same two items in PostgreSQL about the version string and character set as we have on the Framework repo.

Glad to hear you got the conditional sorted out. Odd that the valid power script version wasn't working but the equivalent bat version did. I'm helping Doctrine DBAL add this, with a similar failure, I'll have to switch back to the bat version.

on a side note I tried removing the PHP env var and it results in composer failing on AppVeyor, not sure why but it's apparently a required item

Anything we need to do to make this work? We are having the failed check in the list and people already getting confused.

@rdeutz take a look at the test errors https://ci.appveyor.com/project/joomla/joomla-cms/build/1.0.10/job/el6qnhgw33j8v8se#L971

• Some JToolbarButton tests are not returning the right data
• JGithubGistsTest has an issue \n vs \r\n
• Postgresql and pgsql testGetCollation fails UTF-8 check from LC_COLLATE info on windows
• Postgresql and pgsql SELECT version(); query in the unit test has a trailing comma on windows (there is an rtrim hack in the framework database tests)

any help solving those would be appreciated. (I don't know if anything can be done to solve AppVeyor trying to build without the appveyor.yml file.... maybe something in the settings)

Fixed the github tests. What exactly is happening in the toolbar tests? I'm not exactly clear here. Are we not getting any of that HTML back? Is it some sort of line endings? or what?

@wilsonge It might be the same line endings issue that was in the github tests as I see PHP_EOL in the test I looked at https://github.com/joomla/joomla-cms/blob/staging/tests/unit/suites/libraries/cms/toolbar/button/JToolbarButtonConfirmTest.php#L93-L103

Just a note, we should probably use \n or <br> in the unit tests for HTML, It seems PHP_EOL should generally only be used for file input/output and HTTP headers, unless the file input/output is binary see the top answer in this stackoverflow http://stackoverflow.com/questions/4975411/when-do-i-use-php-eol-instead-of-n-and-vice-versa-ajax-jquery-client-problem

why return $version['server']; is leaving a trailing comma on windows is the root issue to solve

@photodude It's not pg_version() that's returning a version number with a trailing comma, it's the SELECT version(); query the test runs to get the version data to then compare the return value from that.

That query on AppVeyor returns: PostgreSQL 9.4.7, compiled by Visual C++ build 1800, 64-bit
On my MacBook it returns: PostgreSQL 9.5.4 on x86_64-apple-darwin14.5.0, compiled by Apple LLVM version 7.0.2 (clang-700.1.81), 64-bit

As for the collation failure, this test is highly dependent on a database being created with collations containing UTF8 in the string. So it's a mix of the test case being overly assuming and us needing to configure the AppVeyor in a way that makes it work (or just rewriting the test to something less assuming about the local environment, there isn't any dependency I'm aware of for PostgreSQL databases to use a UTF8 collation in combination with our driver).

@mbabker Thanks for the clarification.
For the version compare, I would agree that the rtrim() is necessary since it's from the SELECT version(); query and not a question of our function return. An alternative could be to replace explode() with something like preg_match() to find the version pattern ^(?:(\d+)\.)?(?:(\d+)\.)?(\*|\d+)$

The rtrim() fix is applied here now and I've changed the collation test to just make sure it doesn't return an empty string. That should green light the build.

Looks good now.

Then let's call it good

We should consider moving that rtrim on the postgres version into the driver itself though I guess?

The driver itself is fine. Do a dump within the driver to validate, then do a dump of the result of the query the test is running. The issue is the result of that query the test case is using to ascertain the version number and validate the driver (through whatever API is in use) returns the correct number, NOT the driver itself.

Same explanation as joomla-framework/database#75 (comment) but without the PDO PostgreSQL object since that doesn't exist in the CMS right now.