Neil Conway [EMAIL PROTECTED] writes:
The historical origins of the feature are no excuse for its
deficiencies.
On the other hand, the alleged deficiencies are not bad enough to
justify making non-backwards-compatible changes. If we were getting
routine complaints from the field I might be
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
Neil Conway wrote:
Recently, I was surprised to learn that psql variables are case
sensitive.
like shell variables
Furthermore, there is no error when one attempts to '\set'
a non-existent variable
Well, how are you going to set a new variable if not this way?
One possible justification
Neil Conway wrote:
Perhaps you're suggesting shell variables were used as the design
model for psql's variables (although I can't be sure, you didn't
elaborate). If so, what I'm saying is that this model is not very
friendly for setting psql-internal options, and we'd be better
changing it as
Peter Eisentraut [EMAIL PROTECTED] writes:
Shell variables did serve as a design model, mostly because I found it
better to use *some* model rather than inventing behavior out of thin
air. Consequently, I am sort of biased on this.
It does seem worth pointing out that shell variables have
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
Neil Conway [EMAIL PROTECTED] writes:
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).
