Re: Command Triggers - Mailing list pgsql-hackers

From Dimitri Fontaine
Subject Re: Command Triggers
Date
Msg-id 8762g92x81.fsf@hi-media-techno.com
Whole thread Raw
In response to Re: Command Triggers  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Command Triggers
List pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> writes:
> Dimitri Fontaine <dimitri@2ndQuadrant.fr> writes:
>> I still have some cleaning to do before to prepare the next patch
>> version, such as documentation updating and dealing with rewrites of
>> CHECK and DEFAULT column constraints in CREATE TABLE.  I had to add
>> support for the T_A_Const parser node, and now I'm about to see about
>> adding support for the T_A_Expr one, but I can't help to wonder how the
>> rewriter could work without them.
>
> It doesn't, and it shouldn't have to.  If those nodes get to the
> rewriter then somebody forgot to apply parse analysis.  What's your test
> case?

I'm trying to rewrite the command string from the parse tree, and the
simple example that I use to raise an ERROR is the following:
 create table foo (id serial, foo integer default 1, primary key(id));

I don't know if the parsetree handed by ProcessUtility() has gone
through parse analysis and I don't know if that's needed to execute the
commands, so maybe I have some high level function to call before
walking the parse tree in my new rewriting support?

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


pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Client Messages
Next
From: Hitoshi Harada
Date:
Subject: Re: Patch: Allow SQL-language functions to reference parameters by parameter name