On 12/21/16 8:39 AM, Tom Lane wrote:
Jim Nasby <jim.na...@bluetreble.com> writes:
On 12/21/16 1:55 AM, Andreas Karlsson wrote:
Does your patch handle "ALTER TYPE name ADD ATTRIBUTE ..."? My immediate
guess would be that it could be a cache invalidation thing.
Won't that only happen at end of transaction?
No.
BEGIN;
SELECT plpython_function();
ALTER TYPE ...;
SELECT plpython_function();
COMMIT;
For that matter, the plpython function could execute the ALTER itself
through SPI, or call another function that does so.
(I'm not claiming that the existing code, either in plpython or other
PLs, necessarily handles such all scenarios nicely. But we shouldn't
make it worse.)
Hmm... so I guess the only way we could safely handle this is if any
caching of type info happened via fcinfo->flinfo->fn_extra? Would it
also work if we verified pg_type.(tid,xmin) hadn't changed? (That's what
plpython currently does to verify a row in pg_procedure hasn't changed.)
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
