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

Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)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