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 ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
