On 10/29/12 4:30 PM, Dimitri Fontaine wrote:
>> In some cases we may need to divert or reject DDL, but that's a
>> >secondary concern.
> Reject is already in, just RAISE ERROR from the trigger code. Divert is
> another sell entirely, we currently miss that capability. I'm interested
> into it for some DDLs. Which commands do you want to divert, and at
> exactly what point in their execution? (think about privilege checks,
> lock aquisition, etc).
After further thought... I can't think of any case (right now) where we'd need to divert. We only care about firing up
secondaryeffects from DDL.
>>> >>You would have most of what you're asking. I think that looking into the
>>> >>normalized string to get the information you need when you already know
>>> >>you're looking at an ALTER TABLE statement and you already have the
>>> >>object references (schema, name, oid) is going to make things easier.
>> >
>> >Possibly. We certainly have cases where we need to know what's
>> >happening*inside* the DDL.
> In that cases you would probably need to resort to coding the trigger in
> C so that you can abuse the parsetree. At least the fact that you're
> doing funny things with some commands is easy to get at when doing \dy
> from a psql prompt, an information that's completely lost when using the
> standard process utility hook directly.
>
> I don't see a way to pass down the parse tree in a format easy to use in
> PLpgSQL anyway, but maybe we'll get there at some point. I want to say
> that having to resort to C in some complex cases is good enough for a
> first version of the feature.
+1
--
Jim C. Nasby, Database Architect jim@nasby.net
512.569.9461 (cell) http://jim.nasby.net
