Tom Lane <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend