From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alastair McKinley <a(dot)mckinley(at)analyticsengines(dot)com> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Function definition regression in 15beta1 when specific parameter name (string) is used |
Date: | 2022-05-29 17:43:17 |
Message-ID: | 3498459.1653846197@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Alastair McKinley <a(dot)mckinley(at)analyticsengines(dot)com> writes:
> The following function definition fails in 15beta1 (ok in 14.3):
> create or replace function regexp_match_test(string text,pattern text) returns text[] as
> $$
> select regexp_match(string,pattern);
> $$ language sql;
Commit 1a36bc9db seems to have defined STRING as a type_func_name_keyword,
which strikes me as a pretty horrible trampling on user namespace. That
means you can't have tables or columns named "string" anymore either, and
I'll bet money the latter restriction is going to bite a lot of people.
In a quick experiment here, I don't see any bison complaints if I
back it down to unreserved_keyword, so this seems easily fixable.
I wonder though if we don't need more review of patches that add
partially- or fully-reserved keywords.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Alastair McKinley | 2022-05-29 19:26:20 | Re: Function definition regression in 15beta1 when specific parameter name (string) is used |
Previous Message | Adrian Klaver | 2022-05-29 17:30:24 | Re: Function definition regression in 15beta1 when specific parameter name (string) is used |