Re: Command Triggers - Mailing list pgsql-hackers

On Thu, Dec 15, 2011 at 10:53 AM, Dimitri Fontaine
<dimitri@2ndquadrant.fr> wrote:
> 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?

No.  That's 100% backwards.  We should first decide what functionality
we want, and then decide how we're going to implement it.  If we
arbitrarily decide to force everything that someone might want to
write a trigger on through ProcessUtility_hook, then we're going to
end up being unable to add triggers for some things because they can't
be conveniently forced through ProcessUtility, or else we're going to
end up contorting the code in bizarre ways because we've drawn some
line in the sand that ProcessUtility is the place where triggers have
to get called.

In doing this project, I think we should pay a lot of attention to the
lessons that have been learned developing sepgsql.  I can certainly
understand if your eyes roll back in your head when you hear that,
because that project has been exceedingly long and difficult and shows
no sign of reaching its full potential for at least another few
release cycles.  But I think it's really worth the effort to avoid
pounding our heads against the brick wall twice.  Two things that leap
out at me in this regard are:

(1) It's probably a mistake to assume that we only need one interface.sepgsql has several hooks, and will need more
beforethe dust 
settles.  We have one hook for checking permissions on table names
that appear in DML queries, a second for applying security labels just
after a new SQL object is created, and a third for adjusting the
security context when an sepgsql trusted procedure is invoked.  In a
similar way, I think it's probably futile to think that we can come up
with a one-size-fits-all interface where every command (or operation)
trigger can accept the same arguments.  CREATE TABLE is going to want
to know different stuff than LOCK TABLE or ALTER OPERATOR FAMILY, and
trigger writers are going to want a *convenient* API to that
information, not just the raw query text.

(2) It's almost certainly a mistake to assume that everything you want
to trigger on is a command.  For example, somebody might want to get
control whenever a table gets added to a column, either at table
create time or later.  I don't think most of us would consider CREATE
TABLE bob (a int, b int) to be a create-a-table-with-no-columns
operation plus two add-a-column-to-a-table operations.  But being able
to enforce a column naming policy is no less useful than being able to
enforce a table naming policy, and there are other things you might
want to do there as well (logging, updating metadata, prohibiting use
of certain types, etc.).

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