Re: Command Triggers

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)anarazel(dot)de>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Greg Smith <greg(at)2ndquadrant(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>
Subject: Re: Command Triggers
Date: 2012-01-20 03:00:15
Message-ID: CA+TgmoZyVyNLTdd=480EmMiXOKRBaA28XM6Aiw049SHKZyBPSQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jan 18, 2012 at 4:23 PM, Dimitri Fontaine
<dimitri(at)2ndquadrant(dot)fr> wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
>> Huh, isn't it simpler to just pass the triggers the parse tree *after*
>> parse analysis?  I don't understand what you're doing here.
>
> I didn't realize that the parse analysis is in fact done from within
> standard_ProcessUtility() directly, which means your suggestion is
> indeed workable.
>
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>> It's not the costs I'm worried about so much as the side effects ---
>
> Ok, so I'm now calling the command trigger procedures once the parse
> analysis is done, and guess what, I'm back to the same problem as
> before:
>
>  https://github.com/dimitri/postgres/commit/4bfab6344a554c09f7322e861f9d09468f641bd9
>
>  CREATE TABLE public."ab_foo-bar"
>  (
>    id serial NOT NULL,
>    foo integer default 1,
>    PRIMARY KEY(id)
>  );
>  NOTICE:  CREATE TABLE will create implicit sequence "ab_foo-bar_id_seq" for serial column "ab_foo-bar.id"
>  NOTICE:  snitch: CREATE SEQUENCE
>  ERROR:  unrecognized node type: 904
>
> I'm not sure about the next step, and I'm quite sure I need to stop here
> for tonight. Any advice welcome, I'll be working on that again as soon
> as tomorrow.

My advice is to forget about trying to provide the command string to
the user for the first version of this patch. As you're finding out,
there's no simple, easy, obvious way of doing it, and there are N>0
useful things that can be done without that functionality. I continue
to think that for a first version of this, we should be satisfied to
pass just the OID. I know that's not really what you want, but
there's much to be said for picking a goal that is achievable in the
limited time available, and I fear that setting your sights too high
will lead to something that either (a) doesn't get committed, or (b)
gets committed, but turns out not to work very well, either of which
would be less than ideal.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nikhil Sontakke 2012-01-20 03:38:33 Re: Review of patch renaming constraints
Previous Message Noah Misch 2012-01-20 02:45:05 Re: Re: Add minor version to v3 protocol to allow changes without breaking backwards compatibility