pá 16. 8. 2019 v 17:06 odesílatel Tom Lane <[email protected]> napsal:
> Pavel Stehule <[email protected]> writes: > > čt 15. 8. 2019 v 21:22 odesílatel Tom Lane <[email protected]> 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 >
