From: | Jim Nasby <jim(at)nasby(dot)net> |
---|---|
To: | Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Deparsing DDL command strings |
Date: | 2012-10-30 00:54:40 |
Message-ID: | 508F2550.4030807@nasby.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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 jim(at)nasby(dot)net
512.569.9461 (cell) http://jim.nasby.net
From | Date | Subject | |
---|---|---|---|
Next Message | Markus Wanner | 2012-10-30 08:16:30 | Re: Logical to physical page mapping |
Previous Message | Claudio Freire | 2012-10-29 23:50:54 | Re: [PATCH] Prefetch index pages for B-Tree index scans |