Re: Command Triggers - Mailing list pgsql-hackers

From Dimitri Fontaine
Subject Re: Command Triggers
Date
Msg-id m2boq0hlz2.fsf@2ndQuadrant.fr
Whole thread Raw
In response to Re: Command Triggers  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Command Triggers
Re: Command Triggers
List pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> writes:
>>   create table foo (id serial, foo integer default 1, primary key(id));
>
> That needs to go through transformCreateStmt().  The comments at the
> head of parse_utilcmd.c might be informative.

Indeed, thanks for the heads up here.

> While I've not looked at your patch, I can't escape the suspicion that
> this means you are trying to do the wrong things in the wrong places.
> Calling transformCreateStmt() from some random place is not going to
> make things better; it is going to break CREATE TABLE, which expects to
> do that for itself.

From the comments in the file, it seems like I could either call the
function where I need it on a copy of the parse tree (as made by the
copyObject() function), or reshuffle either when that call happen or
when the calling of the command trigger user functions happens.

At the moment the trigger functions are called from
standard_ProcessUtility() and are given the parse tree as handed over to
that function, before the parse analysis.

We can easily enough copy the parse tree and do another round of parse
analysis on it only when some command triggers are going to get called.
Is the cost of doing so acceptable?

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


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Patch review for logging hooks (CF 2012-01)
Next
From: Peter Eisentraut
Date:
Subject: Re: lots of unused variable warnings in assert-free builds