From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Command Triggers |
Date: | 2011-12-03 21:57:49 |
Message-ID: | 201112032257.49396.andres@anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Friday, December 02, 2011 03:09:55 AM Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > On Thursday, December 01, 2011 07:21:25 PM Tom Lane wrote:
> >> Making this work cleanly would be a bigger deal than I think you're
> >> thinking.
> >
> > Obviously that depends on the definition of clean...
> >
> > Changing the grammar to make that explicit seems to involve a bit too
> > many changes on a first glance. The cheap way out seems to be to make
> > the decision in analyze.c:transformQuery.
> > Would that be an acceptable way forward?
>
> ITYM transformStmt, but yeah, somewhere around there is probably
> reasonable. The way I'm imagining this would work is that IntoClause
> disappears from Query altogether: analyze.c would build a utility
> statement
> CreateTableAs, pull the IntoClause out of the SelectStmt structure and
> put it into the utility statement, and then proceed much as we do for
> ExplainStmt (and for the same reasons).
Ok. Because my book turned out to be boring I started looking at this. I
wonder if wouldn't be better to do check in directly in raw_parser(). The
advantage would be that that magically would fix the issue of not logging
CTAS/select when using log_statement = ddl and we don't need a snapshot or
such so that shouldn't be a problem.
Any arguments against doing so?
Andres
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2011-12-03 22:33:20 | cannot read pg_class without having selected a database / is this a bug? |
Previous Message | Dimitri Fontaine | 2011-12-03 21:57:24 | Re: Why so few built-in range types? |