Re: psql variables
От | Tom Lane |
---|---|
Тема | Re: psql variables |
Дата | |
Msg-id | 10213.1076308554@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | psql variables (Neil Conway <neilc@samurai.com>) |
Ответы |
Re: psql variables
|
Список | pgsql-hackers |
Neil Conway <neilc@samurai.com> 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). [ 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. You could argue it either way about whether their names should be case-sensitive or not. I think it's too late to revisit that choice given that it's not 100% wrong. > 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). That one bothers me a bit too; perhaps Peter can give a justification. > 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. 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. It wouldn't be a bad idea to document some restriction on which names might become predefined variables in future. regards, tom lane
В списке pgsql-hackers по дате отправления: