From: | Neil Conway <neilc(at)samurai(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> |
Cc: | pgsql-patches <pgsql-patches(at)postgresql(dot)org>, Gavin Sherry <swm(at)alcove(dot)com(dot)au> |
Subject: | Re: WIP: CREATE TABLE AS / WITH DATA |
Date: | 2004-09-27 00:23:11 |
Message-ID: | 1096244591.25688.706.camel@localhost.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
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?
-Neil
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-09-27 01:49:35 | Re: void * cast cleanup |
Previous Message | Neil Conway | 2004-09-27 00:17:12 | Re: [HACKERS] cvsup |