Re: Command Triggers - Mailing list pgsql-hackers

Tom Lane <tgl@sss.pgh.pa.us> writes:
> Well, we don't have any such examples, because frankly the nodeToString
> representation is pretty damn unfriendly.  The only code we have that

I tend to agree here, but I know that Jan is convincing enough when he's
saying that it is in fact very friendly.

> does anything with it at all is the readfuncs.c code that turns it back
> into trees of C structs, and that's no help for triggers not themselves
> written in C.  Besides which, readfuncs.c is the poster child for code
> that does have to change every time we tweak the struct definitions.
> We can't tell people to copy that approach.

Providing the same nested C structs thingy in python or perl or tcl
might be feasible and not too sketchy to maintain, but I'm failing to
see how to even approach that for plpgsql.

>> What do you think of removing the parsetree and the BEFORE trigger
>> support (so that trigger function can query the catalogs)?
>
> Well, it gets us out of the business of inventing a suitable API,
> but I think it also reduces the feature to a point of near uselessness.

Not being generic and flexible is not the same thing as not being of any
use at all.  Extension whitelisting is still possible to implement
because all you need to know is the extension's name, then you choose to
let the command string you're given execute or not.  Same with
replication or simple auditing cases, you still have the plain command
string to play with.

Not useful enough for being what we ship in 9.2, I can follow you there,
not useful at all, disagreed.

> Essentially we'd be saying to trigger authors "something changed, feel
> free to inspect the catalogs and see if you can guess what".

No, we'd also be providing the main OID of the object that changed (a
pg_class entry for a CREATE TABLE command, etc), the object name and its
schema name too.  And the command string too.  ALTER TABLE is still
difficult to handle, other more simple commands might be ok.

> Just because the problem is hard doesn't mean you can get away with
> not solving it.

That is the single simplest way of handling it, though, so I had to try
that first.  Now, maybe we can find the right approach to publishing the
parse tree this month still.  Any ideas welcome!

I guess XML would be ok but we don't embed powerful enough tools, and
JSON might be perfect but we would need to have a full blown datatype
and functions to work with that from plpgsql.  What other tree-ish data
type can we have?

EXPLAIN is already able to spit out XML and JSON (and YAML) but the
typical client consuming that output is not running as a backend stored
procedure, so I guess that's not a precedent and we still need something
with a good support (type, operators, walking functions…) to back it.

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