Re: Command Triggers, v16

On Fri, Mar 16, 2012 at 7:42 AM, Dimitri Fontaine
<dimitri(at)2ndquadrant(dot)fr> wrote:
>> I don’t know if this was a problem before that I didn’t spot
>> (probably), but triggers for both ANY COMMAND and ALTER FOREIGN TABLE
>> show a command tag of ALTER TABLE for ALTER FOREIGN TABLE statements
>> where the column is renamed:
>>
>> I don’t think this is the fault of the trigger code because it
>> actually says ALTER TABLE at the bottom, suggesting it’s something
>> already present.  This isn’t the case when adding or dropping columns.
>>  Any comments?
>
> We're building command trigger on top of the existing code. From the
> grammar we can see that an alter table and an alter foreign table are
> processed as the same command.

This seems pretty dicey. I understand your position that it can't be
the job of the command triggers patch to fix every infelicity of the
backend, but on the flip side, code reuse is a good thing. We want to
increase, not decrease, the number of places where the same code can
be used to implement multiple commands that do related things; and
there has to be some way to do that without breaking command triggers.
Moreover, we really don't want the details of how things are handled
internally to be user-visible, because sometimes we refactor things to
improve the quality of our code, and I don't want to get bug reports
when we do that...

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company