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

2022-05-29 Thread Alastair McKinley
> From: Tom Lane 
> Sent: 29 May 2022 18:43
> To: Alastair McKinley 
> Cc: Andrew Dunstan ; pgsql-general@lists.postgresql.org 
> 
> Subject: Re: Function definition regression in 15beta1 when specific 
> parameter name (string) is used 
>  
> Alastair McKinley  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



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

2022-05-29 Thread Tom Lane
Alastair McKinley  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




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

2022-05-29 Thread Adrian Klaver

On 5/29/22 10:29, Adrian Klaver wrote:

On 5/29/22 09:46, Alastair McKinley wrote:

Hi all,





Postgres 15:

https://www.postgresql.org/docs/15/sql-keywords-appendix.html

STRING reserved (can be function or type) non-reserved

Postgres 14:

https://www.postgresql.org/docs/14/sql-keywords-appendix.html

STRING   non-reserved

I don't have a 15 instance available, but I would double quoting 

   ^ think

"string" would work.



Alastair







--
Adrian Klaver
adrian.kla...@aklaver.com




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

2022-05-29 Thread Adrian Klaver

On 5/29/22 09:46, Alastair McKinley wrote:

Hi all,

I was testing an existing codebase with 15beta1 and ran into this issue.

I reduced the test case to an example with works in 14.3, and fails in 15beta1.

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;

The error message is:

 ERROR:  syntax error at or near ","
 LINE 3: select regexp_match(string,pattern);
   ^
Changing the first parameter name from string to anything else (e.g. strin or 
string1) resolves the issue.

The issue also occurs with the "string" parameter name if this is used in a 
plpgsql function like this:

 create or replace function regexp_match_test(string text,pattern text) 
returns text[] as
 $$
 begin
 return (select regexp_match(string,pattern));
 end;
 $$ language plpgsql;

Best regards,


Postgres 15:

https://www.postgresql.org/docs/15/sql-keywords-appendix.html

STRING  reserved (can be function or type)  non-reserved

Postgres 14:

https://www.postgresql.org/docs/14/sql-keywords-appendix.html

STRING  non-reserved

I don't have a 15 instance available, but I would double quoting 
"string" would work.




Alastair




--
Adrian Klaver
adrian.kla...@aklaver.com




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

2022-05-29 Thread Alastair McKinley
Hi all,

I was testing an existing codebase with 15beta1 and ran into this issue.

I reduced the test case to an example with works in 14.3, and fails in 15beta1.

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;

The error message is:

ERROR:  syntax error at or near ","
LINE 3: select regexp_match(string,pattern);
  ^
Changing the first parameter name from string to anything else (e.g. strin or 
string1) resolves the issue.

The issue also occurs with the "string" parameter name if this is used in a 
plpgsql function like this:

create or replace function regexp_match_test(string text,pattern text) 
returns text[] as
$$
begin
return (select regexp_match(string,pattern));
end;
$$ language plpgsql;

Best regards,

Alastair