On Fri, Mar 16, 2012 at 7:42 AM, Dimitri Fontaine <dimi...@2ndquadrant.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers