Re: Function definition regression in 15beta1 when specific parameter name (string) is used

> From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
> Sent: 29 May 2022 18:43
> 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
>
> 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.
>

Yes I would agree, could this potentially break a lot of upgrades?

I checked the release notes and CTRL-F'd for "string" to check in case it had become reserved or become an alias for text, but there is nothing in the release notes at the minute.

> 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