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
