On Wed, Jan 18, 2012 at 4:23 PM, Dimitri Fontaine
<dimitri@2ndquadrant.fr> wrote:
> 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.
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