Обсуждение: pPL/pgSQL restriction on characters for copying types?
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
Вложения
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
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
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
Вложения
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
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
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
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