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

Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)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