psql and Postgres 7.2
In answering a question on SO I discovered this:
\l PRODUCTION
List of databases
Name | Owner | Encoding | Collate | Ctype | Access
privileges
------------+----------+----------+-------------+-------------+-------------------
production | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 |
\c PRODUCTION
FATAL: database "PRODUCTION" does not exist
Previous connection kept
which I traced back to(from Postgres version 14):
src/bin/psql/command.c
/*
* Read and interpret an argument to the \connect slash command.
...
/*
* Ideally we should treat the arguments as SQL identifiers. But for
* backwards compatibility with 7.2 and older pg_dump files, we have to
* take unquoted arguments verbatim (don't downcase them). For now,
* double-quoted arguments may be stripped of double quotes (as if SQL
* identifiers). By 7.4 or so, pg_dump files can be expected to
* double-quote all mixed-case \connect arguments, and then we can get rid
* of OT_SQLIDHACK.
*/
Since Postgres 14 pg_dump only goes back to 8.0 and the \d commands in
psql go back to 7.4, is this something that needs to hang on?
--
Adrian Klaver
adrian.klaver@aklaver.com
Adrian Klaver <adrian.klaver@aklaver.com> writes:
src/bin/psql/command.c
/*
* Ideally we should treat the arguments as SQL identifiers. But for
* backwards compatibility with 7.2 and older pg_dump files, we have to
* take unquoted arguments verbatim (don't downcase them). For now,
* double-quoted arguments may be stripped of double quotes (as if SQL
* identifiers). By 7.4 or so, pg_dump files can be expected to
* double-quote all mixed-case \connect arguments, and then we can get rid
* of OT_SQLIDHACK.
*/
Since Postgres 14 pg_dump only goes back to 8.0 and the \d commands in
psql go back to 7.4, is this something that needs to hang on?
Yeah, I was wondering about that the other day. I agree that we
probably don't need to worry anymore about reading 7.2 pg_dump
output. However, people may be used to/depending on the current
behavior in other ways. It's hard to be sure, but it is worth
noting that it's been a long time since \connect arguments were
only identifiers. We'd have to consider the impact on the
connstring case, too.
regards, tom lane
On 1/21/22 10:49 AM, Tom Lane wrote:
Adrian Klaver <adrian.klaver@aklaver.com> writes:
src/bin/psql/command.c
/*
* Ideally we should treat the arguments as SQL identifiers. But for
* backwards compatibility with 7.2 and older pg_dump files, we have to
* take unquoted arguments verbatim (don't downcase them). For now,
* double-quoted arguments may be stripped of double quotes (as if SQL
* identifiers). By 7.4 or so, pg_dump files can be expected to
* double-quote all mixed-case \connect arguments, and then we can get rid
* of OT_SQLIDHACK.
*/Since Postgres 14 pg_dump only goes back to 8.0 and the \d commands in
psql go back to 7.4, is this something that needs to hang on?Yeah, I was wondering about that the other day. I agree that we
probably don't need to worry anymore about reading 7.2 pg_dump
output. However, people may be used to/depending on the current
behavior in other ways. It's hard to be sure, but it is worth
noting that it's been a long time since \connect arguments were
only identifiers. We'd have to consider the impact on the
connstring case, too.
Maybe at this point it comes down to a revision to the documentation
that indicates the downcasing rules don't apply to identifiers in \connect.
regards, tom lane
--
Adrian Klaver
adrian.klaver@aklaver.com