Re: [HACKERS] Why does plpython delay composite type resolution?

Поиск
Список
Период
Сортировка
От Jim Nasby
Тема Re: [HACKERS] Why does plpython delay composite type resolution?
Дата
Msg-id 0e4b8632-b5d5-f577-8fcc-997643be0933@BlueTreble.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Why does plpython delay composite type resolution?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On 12/21/16 8:39 AM, Tom Lane wrote:
> Jim Nasby <Jim.Nasby@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)



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Craig Ringer
Дата:
Сообщение: Re: [HACKERS] [PATCH] Transaction traceability - txid_status(bigint)
Следующее
От: Joe Conway
Дата:
Сообщение: Re: [HACKERS] Getting rid of "unknown error" in dblink andpostgres_fdw