From: | "Joel Jacobson" <joel(at)compiler(dot)org> |
---|---|
To: | "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | "PostgreSQL Hackers" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: pl/pgsql feature request: shorthand for argument and local variable references |
Date: | 2022-01-06 20:04:17 |
Message-ID: | b6d1f3cd-9297-415d-8e20-8d6339dd9b21@www.fastmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Jan 6, 2022, at 20:24, Pavel Stehule wrote:
> But there is nothing similar in standard.
> Standard doesn't specify any column or table or label names in the custom area.
I think that's an unfair comparison.
This isn't at all the same thing as dictating column or table names.
I merely suggest reusing an existing reserved keyword.
>>čt 6. 1. 2022 v 20:03 odesílatel Joel Jacobson <joel(at)compiler(dot)org> napsal:
>>
>>If "in." would work, due to "in" being a reserved SQL keyword,
>>don't you think the benefits of a SQL standardized solution would outweigh our
>>personal preferences on what word each one of us prefer?
>
>I know that "in" is a reserved word in SQL, but I have not any knowledge of it being used as alias in SQL functions or in >SQL/PSM functions.
Are you concerned "in" might already be used as an alias somehow?
I did some testing:
"in" can be used as a column alias:
=> SELECT 123 AS in;
in
-----
123
(1 row)
But it cannot be used as a table alias, which is what matters:
=> WITH in AS (SELECT 1) SELECT * FROM in;
ERROR: syntax error at or near "in"
=> SELECT * FROM t in;
ERROR: syntax error at or near "in"
=> SELECT * FROM t AS in;
ERROR: syntax error at or near "in"
It's also currently not possible to use it as a PL/pgSQL alias:
=> CREATE FUNCTION f(id int)
RETURNS void
LANGUAGE plpgsql AS $$
DECLARE
in ALIAS FOR $1;
BEGIN
END
$$;
ERROR: syntax error at or near "in"
LINE 5: in ALIAS FOR $1;
/Joel
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2022-01-06 20:34:28 | Re: Bugs in pgoutput.c |
Previous Message | Tom Lane | 2022-01-06 19:58:31 | Re: Bugs in pgoutput.c |