On Thu, Dec 15, 2011 at 05:46:05PM +0100, Dimitri Fontaine wrote:
> Andres Freund <andres@anarazel.de> writes:
> >> Yes, we need to make a decision about that now. Do we want any
> >> ???operation??? to go through ProcessUtility so that hooks and command
> >> triggers can get called?
> > I personally think thats a good idea for most stuff.
> >
> > I don't see that for alter table subcommands and such though.
>
> By subcommand, I mean any operation that a main command do for you and
> that you could have been doing manually with another command, such as
> serial and sequences, primary key and its alter table form, embedded
> checks or not null and its alter table form, etc.
>
> I don't remember that ALTER TABLE implement facilities that are in turn
> calling another command for you?
When ALTER TABLE ALTER TYPE changes an indexed column, it updates the index by
extracting its SQL definition, dropping it, and running that SQL. (Not sure
whether it passes through the code paths to hit your trigger.) We ought not to
promise that ALTER TABLE will always do so. By comparison, we could implement
ALTER TABLE SET NOT NULL on an inheritance tree as several ALTER TABLE ONLY, but
we don't implement it that way. Triggering on top-level commands can be quite
well-defined; triggers on subcommands (as you have defined the term) will risk
firing at different times across major versions. That may just be something to
document.
I think we'll need a way to tell SPI whether a command should be considered a
subcommand or not. A PL/pgSQL function that calls CREATE TABLE had better
fire a trigger, but some SPI usage will qualify as subcommands.
nm
