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

From Pavel Stehule
Subject Re: pgsql: Fix plpgsql to re-look-up composite type names at need.
Date
Msg-id CAFj8pRDri7xNi6uN4aEvSedEuwKTQJid3=Zh3n9EU-AaPq7NjQ@mail.gmail.com
Whole thread Raw
In response to pgsql: Fix plpgsql to re-look-up composite type names at need.  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pgsql: Fix plpgsql to re-look-up composite type names at need.  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-committers
Hi

č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.


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?

Regards

Pavel

pgsql-committers by date:

Previous
From: Etsuro Fujita
Date:
Subject: pgsql: Remove useless bms_free() calls in build_child_join_rel().
Next
From: Tom Lane
Date:
Subject: Re: pgsql: Fix plpgsql to re-look-up composite type names at need.