Re: Command Triggers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> 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 theory you're right. In practice, we're talking about utility
command triggers, that fires on a top-level command.

We're now enlarging the talk about what to do with sub-commands, that is
things done by a command as part of its implementation but that you
could have done separately with another finer grained dedicated
top-level command.

I'm not wanting to implement a general ”event” trigger mechanism where
anyone can come and help define the set of events, and I think what
you're talking about now amounts to be doing that.

Here again, trying to generalize before we have anything useful is a
recipe for failure. I concur that “Process Utility Top-Level Only
Command Triggers” is a pretty limited feature in scope, yet that's what
I want to obtain here, and I think it's useful enough on its own.

If you disagree, please propose a user level scheme where we can fit the
work I'm doing so that I can adapt my patch and implement a part of your
scheme in a future proof way. I'm ready to do that even when I have no
need for what you're talking about, if that's what it takes.

> (1) It's probably a mistake to assume that we only need one interface.
[... useful sepgsql history ...]
> 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.

Are you familiar with the nodeToString() output? That's close to a full
blown XML, JSON or YAML document that you can easily use from a program.
Command triggers functions are not given just a raw text.

When trying to define a more complex API in the line of what you're
referencing here, back at the Cluster Hackers Developer Meeting, it was
devised that the nodeToString() output is all you need. For having
written code that produces it and code that consumes it, Jan has been
very clear that you hardly can do better than that while still being
generic enough.

> 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.).

Are you familiar with the nodeToString() output? What makes you think
that the uses cases you propose here are hard to implement in a command
trigger when given this parse tree string?

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support