| From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
|---|---|
| To: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
| Cc: | Corey Huinker <corey(dot)huinker(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Undefined psql variables |
| Date: | 2017-01-23 18:31:54 |
| Message-ID: | CAKFQuwYBUgEfsMZbWEyUzxDheNFn6=wx9g7Mq3xAMcGEbyJsxg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Jan 23, 2017 at 11:16 AM, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> wrote:
>
> [...] Obviously the \if stuff is things we don't have yet either, but it
>>> seems less likely to have surprising side-effects.
>>>
>>
> I agree, a more generic solution seems better than an ad-hoc one.
>
> 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. psql, by design, attempts to resolve all
strings of the form <:['"]?\w> in a purely textual manner.
David J.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kevin Grittner | 2017-01-23 18:32:42 | Re: [PATCH] Add GUCs for predicate lock promotion thresholds |
| Previous Message | Fabien COELHO | 2017-01-23 18:26:42 | Re: Allowing nonzero return codes from \quit |