From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org, Greg Smith <greg(at)2ndquadrant(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Subject: | Re: Command Triggers |
Date: | 2012-01-18 14:46:14 |
Message-ID: | 20982.1326897974@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>> 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));
That needs to go through transformCreateStmt(). The comments at the
head of parse_utilcmd.c might be informative.
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Jaime Casanova | 2012-01-18 14:46:20 | Re: Measuring relation free space |
Previous Message | Jim Mlodgenski | 2012-01-18 14:19:13 | Re: Client Messages |