Re: [HACKERS] Undefined psql variables
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] Undefined psql variables |
Дата | |
Msg-id | 20243.1485200693@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Undefined psql variables ("David G. Johnston" <david.g.johnston@gmail.com>) |
Ответы |
Re: [HACKERS] Undefined psql variables
|
Список | pgsql-hackers |
"David G. Johnston" <david.g.johnston@gmail.com> writes: > On Mon, Jan 23, 2017 at 11:16 AM, Fabien COELHO <coelho@cri.ensmp.fr> wrote: >> Currently the value of a non existing psql-variable is... its own >> reference:-( >> >> psql> \echo :x >> :x >> >> I'm not sure of the rational, apart from the probable lexer implementation >> point of view. Maybe an empty string or 0 or some configurable value would >> provide better alternative. > The fundamental problem is that: > SELECT 'testing' AS ":tablename" > is perfectly valid SQL code. Yeah, but psql does know not to try to resolve :something inside a quoted literal or identifier. The actual problem is with constructs like SELECT somearray[lower:upper] FROM ... If the user is thinking that's an array subscript not a variable reference, we don't want to break their query when we don't even have a useful thing to contribute. Back in the day, PG allowed ":" as a generic operator name, making this even worse; but I think the only remaining SQL syntax that could include a colon is array slicing. regards, tom lane
В списке pgsql-hackers по дате отправления: