Re: psql variables - Mailing list pgsql-hackers

From Tom Lane
Subject Re: psql variables
Date
Msg-id 10213.1076308554@sss.pgh.pa.us
Whole thread Raw
In response to psql variables  (Neil Conway <neilc@samurai.com>)
Responses Re: psql variables  (Neil Conway <neilc@samurai.com>)
List pgsql-hackers
Neil Conway <neilc@samurai.com> writes:
> Recently, I was surprised to learn that psql variables are case
> sensitive. Furthermore, there is no error when one attempts to '\set'
> a non-existent variable (arguably for good reason: I suppose it's too
> late now to get rid of user-defined psql variables).

[ blinks... ]  This is historical revisionism.  Psql variables were
invented to provide user-defined variables; it is the predefined ones
that are a wart added to the mechanism, not vice versa.

You could argue it either way about whether their names should be
case-sensitive or not.  I think it's too late to revisit that choice
given that it's not 100% wrong.

> While we're on the subject, there are some other design choices in
> this area that seem a bit unfortunate. For example, we don't error out
> on references to undefined variables (so "\echo :x" could be an
> undefined variable or a variable that is set to the empty string, it
> isn't possible to tell).

That one bothers me a bit too; perhaps Peter can give a justification.

> Also, the user can go ahead and overwrite the
> value of built-in variables like HOST and PORT, which doesn't seem
> like a very useful feature.

Again, you're letting the tail wag the dog.  If we did that then any
addition of a new built-in variable would risk breaking existing user
scripts that happened to use that name as an ordinary variable.

It wouldn't be a bad idea to document some restriction on which names
might become predefined variables in future.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [PATCHES] dollar quoting
Next
From: "Alex J. Avriette"
Date:
Subject: Re: RFC: Very large scale postgres support