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 по дате отправления: