Re: Undefined psql variables

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

In response to

Responses

Browse pgsql-hackers by date

  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