čt 4. 1. 2024 v 22:02 odesílatel Tom Lane <t...@sss.pgh.pa.us> napsal:

> Pavel Stehule <pavel.steh...@gmail.com> writes:
> > Now, I think so this simple patch is ready for committers
>
> I pushed this with some editorialization -- mostly, rewriting the
> documentation and comments.  I found that the existing docs for %TYPE
> were not great.  There are two separate use-cases, one for referencing
> a table column and one for referencing a previously-declared variable,
> and the docs were about as clear as mud about explaining that.
>
> I also looked into the problem Pavel mentioned that it doesn't work
> for RECORD.  If you just write "record[]" you get an error message
> that at least indicates it's an unsupported case:
>
> regression=# do $$declare r record[]; begin end$$;
> ERROR:  variable "r" has pseudo-type record[]
> CONTEXT:  compilation of PL/pgSQL function "inline_code_block" near line 1
>
> Maybe we could improve on that, but it would be a lot of work and
> I'm not terribly excited about it.  However, %TYPE fails entirely
> for both "record" and named composite types, and the reason turns
> out to be just that plpgsql_parse_wordtype fails to handle the
> PLPGSQL_NSTYPE_REC case.  So that's easily fixed.
>
> I also wonder what the heck the last half of plpgsql_parse_wordtype
> is for at all.  It looks for a named type, which means you can do
>
> regression=# do $$declare x float8%type; begin end$$;
> DO
>
> but that's just stupid.  You could leave off the %TYPE and get
> the same result.  Moreover, it is inconsistent because
> plpgsql_parse_cwordtype has no equivalent behavior:
>
> regression=# do $$declare x pg_catalog.float8%type; begin end$$;
> ERROR:  syntax error at or near "%"
> LINE 1: do $$declare x pg_catalog.float8%type; begin end$$;
>                                         ^
> CONTEXT:  invalid type name "pg_catalog.float8%type"
>
> It's also undocumented and untested (the code coverage report
> shows this part is never reached).  So I propose we remove it.
>
> That leads me to the attached proposed follow-on patch.
>
> Another thing we could think about, but I've not done it here,
> is to make plpgsql_parse_wordtype and friends throw error
> instead of just returning NULL when they don't find the name.
> Right now, if NULL is returned, we end up passing the whole
> string to parse_datatype, leading to unhelpful errors like
> the one shown above.  We could do better than that I think,
> perhaps like "argument of %TYPE is not a known variable".
>

+1

Regards

Pavel

>
>                         regards, tom lane
>
>

Reply via email to