Re: WIP: CREATE TABLE AS / WITH DATA

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

In response to

Browse pgsql-patches by date

  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