Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-patches by date

Next:From: Tom LaneDate: 2004-09-27 01:49:35
Subject: Re: void * cast cleanup
Previous:From: Neil ConwayDate: 2004-09-27 00:17:12
Subject: Re: [HACKERS] cvsup

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group