psql variables

From: Neil Conway <neilc(at)samurai(dot)com>
To: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: psql variables
Date: 2004-02-09 05:51:49
Message-ID: 87wu6w6bre.fsf@mailbox.samurai.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Glaesemann 2004-02-09 05:57:13 Re: [HACKERS] Linking the previously separated documentation
Previous Message Tom Lane 2004-02-09 05:37:47 Re: Transaction aborts on syntax error.