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 secondary effects 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 j...@nasby.net
512.569.9461 (cell) http://jim.nasby.net
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
