Re: Command Triggers

2011/12/19 Robert Haas <robertmhaas(at)gmail(dot)com>:
> On Mon, Dec 19, 2011 at 9:31 AM, Greg Smith <greg(at)2ndquadrant(dot)com> wrote:
>> That seems pretty sensible; I wouldn't want to make it a hard requirement
>> though.  There are three major ways this could go for 9.2:
>>
>> 1) Nothing is changed in core, the best that can be done is whatever you can
>> cram into an extension.
>>
>> 2) 9.2 is released with Command Triggers using nodeToString() output as the
>> detailed description.  That part is labeled "experimental and the API is
>> expected to change completely in the next release"
>>
>> 3) 9.2 gets enough JSON support to also have an early nodeToJSON API
>> instead.  Now it's labeled "early release and some API changes may be needed
>> in future releases".
>>
>> From the perspective of enabling a developer community to spring up around
>> working in this area, I don't see a huge difference between (2) and (3).
>
> I do.  Anyone coding in PL/pgsql is going to find the nodeToString()
> output unusable, and we can easily provide a built-in JSON datatype
> with enough richness to make that problem go away in time for 9.2.
> People in PL/python and PL/perl may be a bit better off, but I see no
> reason to ship something for 9.2 and then break it for 9.3 when we
> could perfectly well make that compatibility break before the release.
>  (And, in case it's not clear, yes, I am volunteering to do the work,
> if it comes down to that.)

absolutelly

Parsing a some document is not a good way for plpgsql. We can enhance
a diagnostics statement for triggers values.

there should be lot of variables, and it is cheap because we can take
content when it is requested

STATEMENT_NAME,
OBJECT_SCHEMA,
OBJECT_NAME,
OBJECT_TYPE,
OBJECT_OID,
ATTRIBUT_NAME,
ATTRIBUT_OID,
ATTRIBUT_TYPE,
STATEMENT_PARAMETERS_ARRAY

plpgsql is not good for recursive data - can be nice if all necessary
data can be flat.

Regards

Pavel

>
> But before we get bogged down in the data representation, I think we
> need to make a more fundamental decision: to what extent are we OK
> with exporting the parse tree at all, in any form?  Tom is arguing
> that we shouldn't, and I see his point: the recent DROP command rework
> would have broken everybody's command triggers if we had adopted this
> proposal, and that would be a real shame, because I don't particularly
> like the idea that we can't continue to improve the code and refactor
> things because someone out there might be depending on an older and
> less well-considered behavior.
>
> On the flip side, I don't really see any other way to make this
> feature work at all.  I think that AFTER CREATE triggers and BEFORE
> DROP triggers could potentially be implemented by just passing OIDs
> in, and that might be useful enough for many people.  But what about
> ALTER?  I don't see that you're going to be able to write any sort of
> meaningful triggers around ALTER without passing at least some of the
> parse tree information to the trigger function.
>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers