Tom Lane <tgl@sss.pgh.pa.us> writes:
> [ 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.
The historical origins of the feature are no excuse for its
deficiencies.
> 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.
A name conflict with a newly-added variable is very likely to cause
problems in any case, if the new variable does anything at all. For
example, if your pre-7.4 used "AUTOCOMMIT" to mean something other
than what 7.4 thinks it means, your script is probably broken.
On second thought, there's another alternative. Rather than improving
\set, we could invent a new mechanism for setting psql-internal
variables, and leave the \set stuff to user-defined variables. That
way we can define whatever semantics we'd like for the new command
without hindering backward compatibility. We'd need to ensure that
using \set to modify existing psql variable names still works, but
that shouldn't be too difficult.
One downside is that we'd now have *three* different sets of variables
in psql alone (\set, \pset, and \sys_set or whatever it might be
named). We might improve that by amalgamating \pset into \sys_set,
because AFAICS there is no reason for the former to exist.
Comments?
-Neil