On Wed, 2004-09-22 at 23:00, Alvaro Herrera wrote:
> Could that include supporting SELECT INTO as well as both types of
> CREATE TABLE AS? I remember being annoyed by some limitation of one of
> the forms ...
I'm working on implementing this (and Tom's suggestion of creating a new
DestReceiver), and I should have something worth sending to -patches in
a few days.
One note on the implementation: I had originally wanted to distinguish
between SELECT and SELECT INTO in the parser, so that the SelectStmt
parse node could be kept entirely free of SELECT INTO-related detritus.
I wasn't able to figure out how to do this, though: we want to allow
only the left-most SELECT in a set operation tree to contain an INTO
clause. For now, I've settled for keeping an "into" field in SelectStmt,
and transforming SelectStmt -> CreateTableAsStmt in parser/analyze.c if
appropriate. That means you could send a SelectStmt into the analysis
phase and get a utility statement back, but I don't see that as a
problem. Can anyone see a cleaner way to implement this?
In response to
pgsql-patches by date
|Next:||From: Tom Lane||Date: 2004-09-27 01:49:35|
|Subject: Re: void * cast cleanup |
|Previous:||From: Neil Conway||Date: 2004-09-27 00:17:12|
|Subject: Re: [HACKERS] cvsup|