[Bug] 73498 Incorrect SQL generated for pg_copy_to() #2214

Closed
wants to merge 2 commits into
from

Projects

None yet

7 participants

@duncan3dc
Contributor

Postgres uses the DELIMITER keyword since 7.3 (released in 2002).

All currently supported versions of postgres support DELIMITER so I don't think there's any reason to still use DELIMITERS

The following syntax was used before PostgreSQL version 7.3 and is still supported
https://www.postgresql.org/docs/current/static/sql-copy.html#AEN77789

@weltling
Contributor

Please add a test.

Thanks.

@duncan3dc
Contributor

@weltling Doesn't this test already cover it?

@KalleZ
Contributor
KalleZ commented Nov 20, 2016

@duncan3dc I suppose it does, it is just good to have a test specific for this for each bug fix so it is easier to find any regressions that may occur later on :)

@duncan3dc
Contributor

@KalleZ Thinking about it further, I think this change should standalone from the bug. I think something else is causing the bug, and the error message is slightly misleading

@duncan3dc duncan3dc changed the title from [Bug] 73498 Incorrect SQL generated for pg_copy_to() to Update SQL generated for pg_copy_to() Nov 20, 2016
@weltling
Contributor

@duncan3dc nope, it doesn't. Please see the reproduce snippet in the ticket. The linked test uses a table name directly, that tells the difference.

Thanks.

@duncan3dc
Contributor

@weltling I've changed this pr now to just be about updating the DELIMITER syntax, I'll take another look at the actual bug when I get a minute

@duncan3dc duncan3dc changed the base branch to php:PHP-7.0 from php:master Nov 20, 2016
@weltling
Contributor
weltling commented Nov 20, 2016 edited

@duncan3dc but this is still the bugfix to 73498 :) So renaming the PR doesn't sound right. PostgreSQL before 7.3 just doesn't support the sub select syntax. But there are yet two syntax changes in the versions that we support. That's what we need to test, easy done with just modifying the other test.

Thanks.

@php-pulls

Comment on behalf of krakjoe at php.net:

labelling

@php-pulls php-pulls added the Bugfix label Nov 21, 2016
duncan3dc added some commits Nov 20, 2016
@duncan3dc duncan3dc Fix bug #73498
Postgres uses the DELIMITER keyword since 7.3
And WITH is no longer required/used
fb3c6ad
@duncan3dc duncan3dc Add a test for bug 73498 e665797
@duncan3dc duncan3dc changed the title from Update SQL generated for pg_copy_to() to [Bug] 73498 Incorrect SQL generated for pg_copy_to() Nov 21, 2016
@duncan3dc
Contributor

@weltling Sorry for the confusion, thanks for bearing with me. I've added a test and completed the bugfix now

@weltling
Contributor

Merged with 644e290, d36d4c7.

Thank you!

@weltling weltling closed this Nov 22, 2016
@staabm
Contributor
staabm commented Nov 22, 2016 edited

this change effectivly means that support with postgres < 7.3 was dropped, correct? if so, please mention it in the changelog.

@weltling
Contributor

These PostgreSQL versions are already not supported in PHP, besides they're EOL.

Thanks.

@nikic
Contributor
nikic commented Nov 22, 2016

@weltling What is the currently minimal supported version? If pgsql < 7.3 is not supported, there are probably some checks we can drop, e.g. going by config.m4 things like https://github.com/php/php-src/blob/master/ext/pgsql/config.m4#L75.

(It would be nice in general if we could write down minimal versions for all libraries somewhere.)

@weltling
Contributor

@nikic With PostgreSQL - to my current knowledge, the lowest supported in PHP is 8.1. For PHP 7.0 however, at least 9.3 is required for the proper 64-bit support. I was doing research some time ago because of another bug - even for the older EOL'd CentOS, RPMs for PG < 7.3 are not provided officially anymore https://yum.postgresql.org/repopackages.php . So lower than 7.3 is for sure out of question.

Absolutely, having a list of versions defined would be useful. I used to maintain that wiki page for Windows libs https://wiki.php.net/internals/windows/libs , but now it just screams for update as I'd have to kill a half of a day to actualize it :) Meantime, there's also another approach, that i prepare for the dep update automation new SDK http://windows.php.net/downloads/php-sdk/deps/series/ , so it's more or less tracked. Except we in general try to maintain the wide compat, it seems to be hard. The most exts have no dedicated maintainers, who would know fine details. Nowadays, with a small exception, contributors are not concentrated on wider spectrum. And it's more about fixing issues, than tracking new features and versions :( Some initiative could be started, to maintain such a list globally, i'm just not sure it wouldn't end up in some unmaintained state as well.

Thanks.

@weltling
Contributor

Typo : "contributors ARE concentrated on wider spectrum" :)

@bukka
Contributor
bukka commented Dec 6, 2016

@weltling Maybe we could add another row to EXTENSIONS called for example DEPENDENCIES where would be the lowest supported version. Even if it ends up outdated, it will be clear that some versions are not supported so it might useful anyway. Just an idea...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment