[Bug] 73498 Incorrect SQL generated for pg_copy_to()

[duncan3dc]

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]

Please add a test.

Thanks.

[duncan3dc]

@weltling Doesn't this test already cover it?

[KalleZ]

@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]

@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

[weltling]

@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]

@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

[weltling]

@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

[duncan3dc]

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

[weltling]

Merged with 644e290, d36d4c7.

Thank you!

[staabm]

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

[weltling]

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

Thanks.

[nikic]

@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]

@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]

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

[bukka]

@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...