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). That leads to
confusing situations like the following:
nconway=# \set autocommit off
nconway=# create table def (a int, b int);
CREATE TABLE
nconway=# abort;
WARNING: there is no transaction in progress
ROLLBACK
One possible justification for this behavior is that it allows a
simple naming convention to distinguish user-defined variables from
psql-internal variables. Is that the case?
If so, can't we achieve that aim via some other means? For example, by
requiring a common prefix for psql-internal variables, akin to 'pg_*'
for system catalogs prior to 7.3.
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). 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.
Now that 7.4's psql includes some genuinely useful psql variables
like AUTOCOMMIT and VERBOSITY, it seems likely this feature will see
more usage, so it would be nice to clean it up a bit.
-Neil
