From: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andreas Karlsson <andreas(at)proxel(dot)se>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Why does plpython delay composite type resolution? |
Date: | 2016-12-22 00:04:46 |
Message-ID: | 0e4b8632-b5d5-f577-8fcc-997643be0933@BlueTreble.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 12/21/16 8:39 AM, Tom Lane wrote:
> Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)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)
From | Date | Subject | |
---|---|---|---|
Next Message | Joe Conway | 2016-12-22 00:12:34 | Re: Getting rid of "unknown error" in dblink and postgres_fdw |
Previous Message | Craig Ringer | 2016-12-21 23:49:40 | Re: [PATCH] Transaction traceability - txid_status(bigint) |