Thread: 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