Pavel Stehule <pavel.stehule@gmail.com> writes:
> čt 15. 8. 2019 v 21:22 odesílatel Tom Lane <tgl@sss.pgh.pa.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?
> 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.)
regards, tom lane
