have to agree ... psql behaviour should be an extension of the backend's
...
On Mon, 31 Jan 2000, Tom Lane wrote:
> 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
>
> ************
>
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org