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  (Fabien COELHO <coelho@cri.ensmp.fr>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] [PATCH] Generic type subscription
Следующее
От: Jesper Pedersen
Дата:
Сообщение: Re: [HACKERS] Microvacuum support for Hash Index