Re: Fix bug in handling of dropped columns in pltcl triggers

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Fix bug in handling of dropped columns in pltcl triggers
Дата
Msg-id 19404.1478615945@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Fix bug in handling of dropped columns in pltcl triggers  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Список pgsql-hackers
Jim Nasby <Jim.Nasby@bluetreble.com> writes:
> On 11/4/16 4:28 PM, Tom Lane wrote:
>> It's possible that it'd make sense for pltcl_trigger_handler to ignore
>> empty-string column names in the returned list, so that the behavior
>> with stupid trigger functions would be a bit more forgiving; but that
>> is more or less independent of this patch.

> I'm a bit reluctant to do that since it'd be nice to be consistent with 
> regular pltcl functions returning composites. The same kind of issue 
> exists with the holes in $TG_relatts; we shouldn't be exposing the 
> details of attnum that way. Any code that's expecting those holes is 
> going to blow up after a dump/restore anyway.

Hm.  Offhand it seems like the functions that pltcl itself exposes don't
really do anything that would depend on $TG_relatts indexes matching
physical column numbers.  The only way you could write a pltcl function
that would depend on that would be to have it do some catalog queries that
expect the indexes to match pg_attribute.attnum.  That's possible I guess
but it seems neither likely nor good practice.

I think I'd be in favor of trying to remove the business about having
empty-string entries in $TG_relatts.  Do you want to draft a patch
for that?
        regards, tom lane



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Add support for SRF and returning composites to pl/tcl
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: Row level security implementation in Foreign Table in Postgres