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

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

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.klaver@aklaver.com

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.klaver@aklaver.com

Alastair McKinley <a.mckinley@analyticsengines.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: Tom Lane <tgl@sss.pgh.pa.us>
> Sent: 29 May 2022 18:43
> To: Alastair McKinley <a.mckinley@analyticsengines.com>
> Cc: Andrew Dunstan <andrew@dunslane.net>; pgsql-general@lists.postgresql.org <pgsql-general@lists.postgresql.org>
> Subject: Re: Function definition regression in 15beta1 when specific parameter name (string) is used
>
> Alastair McKinley <a.mckinley@analyticsengines.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