Re: WIP: CREATE TABLE AS / WITH DATA
От
Neil Conway
Тема
Re: WIP: CREATE TABLE AS / WITH DATA
Дата
Msg-id
1096244591.25688.706.camel@localhost.localdomain
Ответ на
Re: WIP: CREATE TABLE AS / WITH DATA (Alvaro Herrera)
Список
Дерево обсуждения
WIP: CREATE TABLE AS / WITH DATA Neil Conway <neilc@samurai.com>
Re: WIP: CREATE TABLE AS / WITH DATA Alvaro Herrera <alvherre@dcc.uchile.cl>
Re: WIP: CREATE TABLE AS / WITH DATA Neil Conway <neilc@samurai.com>
Re: WIP: CREATE TABLE AS / WITH DATA Tom Lane <tgl@sss.pgh.pa.us>
Re: WIP: CREATE TABLE AS / WITH DATA Gavin Sherry <swm@linuxworld.com.au>
Re: WIP: CREATE TABLE AS / WITH DATA Neil Conway <neilc@samurai.com>
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
В списке pgsql-patches по дате отправления