Re: Command Triggers
Dimitri Fontaine <dimitri@2ndquadrant.fr>
From: Dimitri Fontaine <dimitri@2ndQuadrant.fr>
To: Alvaro Herrera <alvherre@commandprompt.com>
Cc: Dimitri Fontaine <dimitri@2ndquadrant.fr>, Tom Lane <tgl@sss.pgh.pa.us>, Robert Haas <robertmhaas@gmail.com>, Andres Freund <andres@anarazel.de>, Pg Hackers <pgsql-hackers@postgresql.org>, Greg Smith <greg@2ndquadrant.com>, Bruce Momjian <bruce@momjian.us>
Date: 2012-01-18T21:23:14Z
Lists: 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 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.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support