From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
Cc: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, Corey Huinker <corey(dot)huinker(at)gmail(dot)com>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Undefined psql variables |
Date: | 2017-01-23 19:44:53 |
Message-ID: | 20243.1485200693@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> On Mon, Jan 23, 2017 at 11:16 AM, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Jesper Pedersen | 2017-01-23 19:53:35 | Re: Microvacuum support for Hash Index |
Previous Message | Tom Lane | 2017-01-23 19:36:00 | Re: [PATCH] Generic type subscription |