From: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> |
---|---|
To: | pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | psql and Postgres 7.2 |
Date: | 2022-01-21 18:35:59 |
Message-ID: | a6d05cab-39f1-7c10-a19a-0889e0941bb3@aklaver.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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(dot)klaver(at)aklaver(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2022-01-21 18:41:04 | Re: Using a different column name in a foreign table |
Previous Message | Alanoly Andrews | 2022-01-21 18:32:22 | RE: Using a different column name in a foreign table |