Re: [HACKERS] Re: Regress tests reveal *serious* psql bug
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] Re: Regress tests reveal *serious* psql bug |
Дата | |
Msg-id | 8978.947658153@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Re: Regress tests reveal *serious* psql bug (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: [HACKERS] Re: Regress tests reveal *serious* psql bug
|
Список | pgsql-hackers |
Bruce Momjian <pgman@candle.pha.pa.us> writes: > I think we can live with requiring a variable name to start with an > alphabetic or underscore. > SELECT a[1:2] > is clear and > SELECT a[1:myvar] > expands to SELECT a[1]. No go --- SELECT a[1:b] where b is a field name is a valid query currently. I don't really see exactly what the benefit is of assuming that :foo should expand to nothing rather than :foo, in the absence of an actual definition for :foo. My feeling is that a safe solution would be (a) psql doesn't do variables at all without an explicitly enabling command line switch; and (b) if psql sees:foo where foo is not defined, it spits out an error message. Accepting undeclared variables went out with Basic and Fortran; why are we intent on re-inventing a concept that's so obviously dangerous? > In fact, I think it should be an error to reference a variable that is > not defined. This will catch accidental references too. If you > reference a variable that does not exist like :myvar, it passes the > literal :myvar to the backend. That's two different answers, not one... but I could live with either one of them... regards, tom lane
В списке pgsql-hackers по дате отправления: