Neil Conway <[EMAIL PROTECTED]> writes: > No equivalent functionality has been added to SELECT INTO: there > isn't a convenient syntax for it that I could see, and in any case > CREATE TABLE AS has always offered a superset of the functionality of > SELECT INTO. Therefore, I don't view this as a problem.
I agree on that. > The implementation is a tad messy (it would be nice if CREATE TABLE AS > were a distinct node, to avoid needing to clutter up SelectStmt > further). Yeah, I have been wanting for awhile to redesign the parse representation of CREATE TABLE AS/SELECT INTO. It's not obvious exactly what to do though. > I also needed to add an additional production to avoid a > shift/reduce conflict in the parser (see the XXX note in the patch > itself). This is a fairly standard way of avoiding conflicts --- looks fine to me. One thing that is *not* fine is something that I see had snuck past me in the previous WITH OIDS patch. It is not okay for gram.y or scan.l to be looking at GUC variables --- that creates synchronization issues. (Consider a single querystring containing a SET followed by something that depends on the SET value. The whole string will be parsed before the SET is applied.) The references to default_with_oids have to be postponed to analyze.c's processing. Compare the way that inhOpt has an INH_DEFAULT setting --- you probably need the same kind of solution for the WITH OIDS options. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match