Thread: psql and Postgres 7.2

psql and Postgres 7.2

From
Adrian Klaver
Date:
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



Re: psql and Postgres 7.2

From
Tom Lane
Date:
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



Re: psql and Postgres 7.2

From
Adrian Klaver
Date:
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