From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Neil Conway <neilc(at)samurai(dot)com> |
Cc: | PostgreSQL Patches <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: add "WITH OIDS" to CREATE TABLE AS |
Date: | 2004-01-06 19:57:23 |
Message-ID: | 22907.1073419043@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Neil Conway <neilc(at)samurai(dot)com> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Claudio Natoli | 2004-01-06 22:04:46 | Re: fork/exec patch: pre-CreateProcess finalization |
Previous Message | Tom Lane | 2004-01-06 19:46:03 | Re: move 'Value' node into separate file |