Re: Command Triggers - Mailing list pgsql-hackers

From Dimitri Fontaine
Subject Re: Command Triggers
Date
Msg-id m2pqegg0xp.fsf@2ndQuadrant.fr
Whole thread Raw
In response to Re: Command Triggers  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: Command Triggers  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Alvaro Herrera <alvherre@commandprompt.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@sss.pgh.pa.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
TABLEwill create implicit sequence "ab_foo-bar_id_seq" for serial column "ab_foo-bar.id" NOTICE:  snitch: CREATE
SEQUENCEERROR:  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.

Regards,
-- 
Dimitri Fontaine
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support


pgsql-hackers by date:

Previous
From: Jim Nasby
Date:
Subject: Re: Vacuum rate limit in KBps
Next
From: Marti Raudsepp
Date:
Subject: Re: Patch review for logging hooks (CF 2012-01)