> From: Tom Lane <tgl@xxxxxxxxxxxxx> > Sent: 29 May 2022 18:43 > To: Alastair McKinley <a.mckinley@xxxxxxxxxxxxxxxxxxxx> > Cc: Andrew Dunstan <andrew@xxxxxxxxxxxx>; pgsql-general@xxxxxxxxxxxxxxxxxxxx <pgsql-general@xxxxxxxxxxxxxxxxxxxx> > Subject: Re: Function definition regression in 15beta1 when specific parameter name (string) is used > > Alastair McKinley <a.mckinley@xxxxxxxxxxxxxxxxxxxx> 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
