Neil Conway <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
