Peter Eisentraut <peter_e@gmx.net> writes:
> It seems pretty straightforward and useful, so I'm not sure where your
> hesitation is coming from.
If you're talking about my hesitation to consider what we have now as
marketing material worthy, it comes from the fact that I don't have a
use case where I don't need specific information about the SQL objects
involved in the command, or the Normalized Command String.
> Based in this, I could add some documentation in the coming weeks.
I intend to be working on this $soon too.
> I don't think we have time to add support for this to the in-tree PLs.
> But I was thinking we should at least check all PLs out there that they
> don't crash if they are presented with an event trigger function,
> because if you code a PL like this:
>
> if (CALLED_AS_TRIGGER(fcinfo) {
> // it's a trigger
> }
> else {
> // it's a normal call
> }
>
> there might be some trouble.
As it happens I forgot about that part. Yes the API did change in a way
that's not visible at compile time, and IMV that's a bug we need to be
fixing.
The simple way to have at it seems to involve adding a test branch for
event triggers and reporting an ERROR ERRCODE_FEATURE_NOT_SUPPORTED, the
other way to fix that is to actually inclue the support for event
trigger.
As you did the work for PLsh you know how much (little) is involved. If
you want to consider a patch against one of those for adding even
trigger support (in order to have more data to decice), let me know,
I'll prepare that.
Regards,
--
Dimitri Fontaine 06 63 07 10 78
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support