Re: Case-folding bogosity in new psql - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Case-folding bogosity in new psql
Date
Msg-id 9761.949331323@sss.pgh.pa.us
Whole thread Raw
In response to Re: Case-folding bogosity in new psql  (Peter Eisentraut <e99re41@DoCS.UU.SE>)
Responses Re: [HACKERS] Re: Case-folding bogosity in new psql
Re: Case-folding bogosity in new psql
List pgsql-hackers
Peter Eisentraut <e99re41@DoCS.UU.SE> writes:
> This is not a bogosity if you read and understand the psql grammar.

In other words, you have (by fiat and with no discussion AFAIR) decided
to change psql's "grammar" so that its handling of names is inconsistent
with the backend's.  That might be OK if psql were an independent
product, but it's not.  There are already enough discrepancies between
parsing of backslash commands and parsing of SQL commands; do we need
to add more?

> Quotes
> are for protecting whitespace and other metacharacters. For example, in
> 6.5 there was no good way to connect (\c) to a database with a space in
> the name.

That indicates that \c failed to accept quoted names properly --- but
that's just a bug in \c, not a reason to transfer the same breakage
to other places.

> The conceptual problem I would have with your idea is that command option
> interpretation would be inconsistent. For example \e FILE should surely
> not cause any lower-casing to happen.

No, but a filename is not an SQL name.  Claiming that filename
interpretation must govern SQL name interpretation is about like
claiming that psql should misinterpret SQL names that happen to
match file names in your current directory.

I think that you have reduced usability considerably in order not to
have to distinguish SQL names and file names in some parts of your
code.  That's a design error IMHO.

> What do other people say about this?

I'll wait for other reactions ... but I am not happy.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Hiroshi Inoue"
Date:
Subject: Duplicate index check in btbuild
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] Another nasty cache problem