Re: pgsql: Fix plpgsql to re-look-up composite type names at need.

pá 16. 8. 2019 v 17:06 odesílatel Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> napsal:

> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
> > čt 15. 8. 2019 v 21:22 odesílatel Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> napsal:
> >> I'm slightly hesitant to back-patch this into v11, because it changes
> >> the contents of struct PLpgSQL_type as well as the signature of
> >> plpgsql_build_datatype(), so in principle it could break code that is
> >> poking into the innards of plpgsql. However, the only popular extension
> >> of that ilk is pldebugger, and it doesn't seem to be affected. Since
> >> this is a regression for people who were relying on the old behavior,
> >> it seems worth taking the small risk of causing compatibility issues.
>
> > this change breaks compilation plpgsql_check extension.
>
> plpgsql_check? Why would that need to call plpgsql_build_datatype?
>

It is used for check of expressions related to plpgsql CASE stmt. CASE
variable type is computed dynamically from CASE expr.

> > Backpatching changed plpgsql_build_datatype was not good idea. Now, I
> have
> > not a idea how to ensure compilation on 11 and higher
> > Can you add some symbol to source code, so four parameters of
> > plpgsql_build_datatype should be used?
>
> That wouldn't help you much, because it would only tell you which
> version you were compiling against, not what you were executing in.
>
> You might be best off to put your own copy of the new version of
> plpgsql_build_datatype into the v11 extension, and call that all
> the time. When executing in an older server, it would generate
> structs with some extra fields that plpgsql wouldn't use, but
> that shouldn't hurt anything. (You could likely get away with
> setting the new fields to nulls/zeroes even for composite types,
> shortening your extra code a bit. They'd only matter for
> compiled trees that survive across queries, which I imagine
> plpgsql_check doesn't need to deal with.)
>

I though more time about it and problem is only if somebody will try
compile plpgsql_check against stable Postgres 11. I can use constraint

#ifdef PG_VERSION_NUM > 110005

Almost all people uses plpgsql_check against some packaged postgres, so
this constraint should to work.

I can ignore already released PostgreSQL 12, because it should not be used
in production mode.

Pavel

>
>
> regards, tom lane
>