Re: Fix bug in handling of dropped columns in pltcl triggers - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Fix bug in handling of dropped columns in pltcl triggers
Date
Msg-id 19404.1478615945@sss.pgh.pa.us
Whole thread Raw
In response to Re: Fix bug in handling of dropped columns in pltcl triggers  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: Add support for SRF and returning composites to pl/tcl
Next
From: Stephen Frost
Date:
Subject: Re: Row level security implementation in Foreign Table in Postgres