Thread: pPL/pgSQL restriction on characters for copying types?

pPL/pgSQL restriction on characters for copying types?

From
Thiemo Kellner
Date:
Hi

My names can contain a special character (⠒), e.g. to separate the 
donator object from the name or the name from the type. Typically, I use 
this with foreign keys, e.g. table PARENT has the surrogate key ID, the 
table CHILD would then have the column PARENT⠒ID. That way, I can use 
the underscore to segment column names like yet_another_column_name. I 
do not like camel-case in that case because names do not have to be case 
sensitive.

However, I want to create a (trigger) function to impose data 
consistency. For that purpose, I try to copy the data type of a PL/pgSQL 
variable from the base object, a view in that case. Trying so, I get the 
following error on installation of the function.

V⠒NODE_TYPE⠒NAME                NODE⠒V.NODE_TYPE⠒NAME%type := null;

Syntax error at "%" … invalid type name. If I use the actual type of the 
column, all is fine.

V⠒NODE_TYPE⠒NAME text;

Please find attached script files of objects directly involved in the 
trigger function.

Is there something, I am doing wrongly?

Kind Regards

Thiemo
Attachment

Re: pPL/pgSQL restriction on characters for copying types?

From
Thiemo Kellner
Date:
Oh, I totally forgot to mention that I ran the scripts with DbVisualizer 
against a 16.1 (Debian 16.1-1.pgdg110+1) server using PostgreSQL JDBC 
Driver 42.6.0 .

Am 26.02.2024 um 16:51 schrieb Thiemo Kellner:
> Hi
> 
> My names can contain a special character (⠒), e.g. to separate the 
> donator object from the name or the name from the type. Typically, I use 
> this with foreign keys, e.g. table PARENT has the surrogate key ID, the 
> table CHILD would then have the column PARENT⠒ID. That way, I can use 
> the underscore to segment column names like yet_another_column_name. I 
> do not like camel-case in that case because names do not have to be case 
> sensitive.
> 
> However, I want to create a (trigger) function to impose data 
> consistency. For that purpose, I try to copy the data type of a PL/pgSQL 
> variable from the base object, a view in that case. Trying so, I get the 
> following error on installation of the function.
> 
> V⠒NODE_TYPE⠒NAME                NODE⠒V.NODE_TYPE⠒NAME%type := null;
> 
> Syntax error at "%" … invalid type name. If I use the actual type of the 
> column, all is fine.
> 
> V⠒NODE_TYPE⠒NAME text;
> 
> Please find attached script files of objects directly involved in the 
> trigger function.
> 
> Is there something, I am doing wrongly?
> 
> Kind Regards
> 
> Thiemo



Re: pPL/pgSQL restriction on characters for copying types?

From
Tom Lane
Date:
Thiemo Kellner <thiemo@gelassene-pferde.biz> writes:
> However, I want to create a (trigger) function to impose data 
> consistency. For that purpose, I try to copy the data type of a PL/pgSQL 
> variable from the base object, a view in that case. Trying so, I get the 
> following error on installation of the function.

> V⠒NODE_TYPE⠒NAME                NODE⠒V.NODE_TYPE⠒NAME%type := null;

> Syntax error at "%" … invalid type name. If I use the actual type of the 
> column, all is fine.

FWIW, I couldn't reproduce this with the fragmentary scripts you
provided.  I suspect the problem is not about the special characters
in the names, rather about search_path not including the NODE⠒V view.
Consider schema-qualifying the view name, or attaching a "SET
search_path" clause to the function.

            regards, tom lane



Re: pPL/pgSQL restriction on characters for copying types?

From
Thiemo Kellner
Date:
Thanks for the hint and care. The install script has a set statement 
already and I now added the search_path clause to no avail. Please find 
the entire code attached and a screenshot from the error.

Am 26.02.2024 um 17:35 schrieb Tom Lane:
> Thiemo Kellner <thiemo@gelassene-pferde.biz> writes:
>> However, I want to create a (trigger) function to impose data
>> consistency. For that purpose, I try to copy the data type of a PL/pgSQL
>> variable from the base object, a view in that case. Trying so, I get the
>> following error on installation of the function.
> 
>> V⠒NODE_TYPE⠒NAME                NODE⠒V.NODE_TYPE⠒NAME%type := null;
> 
>> Syntax error at "%" … invalid type name. If I use the actual type of the
>> column, all is fine.
> 
> FWIW, I couldn't reproduce this with the fragmentary scripts you
> provided.  I suspect the problem is not about the special characters
> in the names, rather about search_path not including the NODE⠒V view.
> Consider schema-qualifying the view name, or attaching a "SET
> search_path" clause to the function.
> 
>             regards, tom lane
Attachment

Re: pPL/pgSQL restriction on characters for copying types?

From
Adrian Klaver
Date:
On 2/26/24 08:53, Thiemo Kellner wrote:
> Thanks for the hint and care. The install script has a set statement 
> already and I now added the search_path clause to no avail. Please find 
> the entire code attached and a screenshot from the error.

I quick test:

create table type_test(NODE_TYPE⠒NAME text);

  \d type_test
                 Table "public.type_test"
      Column     | Type | Collation | Nullable | Default
----------------+------+-----------+----------+---------
  node_type⠒name | text |           |

CREATE OR REPLACE FUNCTION public.type_test_fnc()
  RETURNS void
  LANGUAGE plpgsql
AS $function$
DECLARE
     type_name  type_test.node_type⠒name%TYPE :=NULL;
BEGIN
     RAISE NOTICE 'TEST';
END;

$function$

select type_test_fnc();
NOTICE:  TEST
  type_test_fnc
---------------

Shows that it is not the name itself that is the problem, at least in my 
case. I'm going to say it as Tom Lane said, there is a search_path 
issue. I tried to follow all the set search_path calls in your code and 
got lost as to where that ended up. I would try a simple test case, 
using psql, like above to verify that it is not the name in your case 
either. Assuming that works then you will need to track down what the 
actual search_path is when you run the function.


> 
> Am 26.02.2024 um 17:35 schrieb Tom Lane:
>> Thiemo Kellner <thiemo@gelassene-pferde.biz> writes:
>>> However, I want to create a (trigger) function to impose data
>>> consistency. For that purpose, I try to copy the data type of a PL/pgSQL
>>> variable from the base object, a view in that case. Trying so, I get the
>>> following error on installation of the function.
>>
>>> V⠒NODE_TYPE⠒NAME                NODE⠒V.NODE_TYPE⠒NAME%type := null;
>>
>>> Syntax error at "%" … invalid type name. If I use the actual type of the
>>> column, all is fine.
>>
>> FWIW, I couldn't reproduce this with the fragmentary scripts you
>> provided.  I suspect the problem is not about the special characters
>> in the names, rather about search_path not including the NODE⠒V view.
>> Consider schema-qualifying the view name, or attaching a "SET
>> search_path" clause to the function.
>>
>>             regards, tom lane

-- 
Adrian Klaver
adrian.klaver@aklaver.com




Re: pPL/pgSQL restriction on characters for copying types?

From
Thiemo Kellner
Date:
Shame on me. My bad. It was the order of installation that did not work. 
Sorry for that. I was mislead by the error message. If an object is 
missing I would not expect an invalid type name message.

Thanks

Am 26.02.2024 um 17:53 schrieb Thiemo Kellner:
> Thanks for the hint and care. The install script has a set statement 
> already and I now added the search_path clause to no avail. Please find 
> the entire code attached and a screenshot from the error.
> 
> Am 26.02.2024 um 17:35 schrieb Tom Lane:
>> Thiemo Kellner <thiemo@gelassene-pferde.biz> writes:
>>> However, I want to create a (trigger) function to impose data
>>> consistency. For that purpose, I try to copy the data type of a PL/pgSQL
>>> variable from the base object, a view in that case. Trying so, I get the
>>> following error on installation of the function.
>>
>>> V⠒NODE_TYPE⠒NAME                NODE⠒V.NODE_TYPE⠒NAME%type := null;
>>
>>> Syntax error at "%" … invalid type name. If I use the actual type of the
>>> column, all is fine.
>>
>> FWIW, I couldn't reproduce this with the fragmentary scripts you
>> provided.  I suspect the problem is not about the special characters
>> in the names, rather about search_path not including the NODE⠒V view.
>> Consider schema-qualifying the view name, or attaching a "SET
>> search_path" clause to the function.
>>
>>             regards, tom lane



Re: pPL/pgSQL restriction on characters for copying types?

From
Adrian Klaver
Date:
On 2/26/24 09:30, Thiemo Kellner wrote:
> Shame on me. My bad. It was the order of installation that did not work. 
> Sorry for that. I was mislead by the error message. If an object is 
> missing I would not expect an invalid type name message.

For all the code knows it could be just a misspelling.

> 
> Thanks
> 
> Am 26.02.2024 um 17:53 schrieb Thiemo Kellner:
>> Thanks for the hint and care. The install script has a set statement 
>> already and I now added the search_path clause to no avail. Please 
>> find the entire code attached and a screenshot from the error.
>>
>> Am 26.02.2024 um 17:35 schrieb Tom Lane:
>>> Thiemo Kellner <thiemo@gelassene-pferde.biz> writes:
>>>> However, I want to create a (trigger) function to impose data
>>>> consistency. For that purpose, I try to copy the data type of a 
>>>> PL/pgSQL
>>>> variable from the base object, a view in that case. Trying so, I get 
>>>> the
>>>> following error on installation of the function.
>>>
>>>> V⠒NODE_TYPE⠒NAME                NODE⠒V.NODE_TYPE⠒NAME%type := null;
>>>
>>>> Syntax error at "%" … invalid type name. If I use the actual type of 
>>>> the
>>>> column, all is fine.
>>>
>>> FWIW, I couldn't reproduce this with the fragmentary scripts you
>>> provided.  I suspect the problem is not about the special characters
>>> in the names, rather about search_path not including the NODE⠒V view.
>>> Consider schema-qualifying the view name, or attaching a "SET
>>> search_path" clause to the function.
>>>
>>>             regards, tom lane
> 
> 

-- 
Adrian Klaver
adrian.klaver@aklaver.com




Re: pPL/pgSQL restriction on characters for copying types?

From
Tom Lane
Date:
Adrian Klaver <adrian.klaver@aklaver.com> writes:
> On 2/26/24 09:30, Thiemo Kellner wrote:
>> Shame on me. My bad. It was the order of installation that did not work.
>> Sorry for that. I was mislead by the error message. If an object is
>> missing I would not expect an invalid type name message.

> For all the code knows it could be just a misspelling.

I think Thiemo's got a point: "invalid type name" isn't the sort
of phrasing we'd normally use.  Compare

regression=# select 0::foo;
ERROR:  type "foo" does not exist

regression=# create function f() returns foo.bar%type as 'select 1' language sql;
ERROR:  relation "foo" does not exist

regression=# create function f() returns void language plpgsql as
$$declare x foo.bar%type; begin end$$;
ERROR:  syntax error at or near "%"
LINE 2: $$declare x foo.bar%type; begin end$$;
                           ^
CONTEXT:  invalid type name "foo.bar%type"

Digging in the plpgsql code, I notice that there's already a comment
complaining about how this is unhelpful:

     * If we have a simple or composite identifier, check for %TYPE and
     * %ROWTYPE constructs.  (Note that if plpgsql_parse_wordtype et al fail
     * to recognize the identifier, we'll fall through and pass the whole
     * string to parse_datatype, which will assuredly give an unhelpful
     * "syntax error".  Should we try to give a more specific error?)

which I believe I wrote not very long ago as part of an unrelated
change (digs ... yeah, see 5e8674dc8).  I'd not gone further than that
because the previous behavior was no better, but maybe it's time to
work harder.  The main problem is that this code doesn't know whether
the appropriate complaint is about a table not existing or a table
column not existing.  Maybe it's okay to let plpgsql_parse_wordtype
etc throw the error for themselves, though.

            regards, tom lane