From: | Gavin Sherry <swm(at)linuxworld(dot)com(dot)au> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Neil Conway <neilc(at)samurai(dot)com>, Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>, 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-23 04:37:31 |
Message-ID: | Pine.LNX.4.58.0409231434530.10839@linuxworld.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
On Thu, 23 Sep 2004, Tom Lane wrote:
> Neil Conway <neilc(at)samurai(dot)com> writes:
> > 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?
>
> > Right; my thinking is to have the parser construct SELECT INTO as a
> > CreateTableAsStmt. That way all the code for creating the "into"
> > relation is centralized in one place.
>
> Another thing that would be really nice would be to get rid of all the
> warty special cases for SELECT INTO in executor/execMain.c. I have
> thought about handling this stuff in a new tuple receiver type (cf
> tcop/dest.h, dest.c) but haven't really pursued it. I also have some
That's a pretty good idea. I was also thinking about this and wondering
about the optimisations we could make. Skip WAL and just fsync() the file
at the end (or dump whole blocks into WAL if we're archiving). Its a bit
of a niche case though.
Gavin
From | Date | Subject | |
---|---|---|---|
Next Message | Neil Conway | 2004-09-23 07:42:33 | trivial cleanup: ExecProcAppend |
Previous Message | Tom Lane | 2004-09-23 04:15:44 | Re: WIP: CREATE TABLE AS / WITH DATA |