Tom Lane [EMAIL PROTECTED] writes:
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.
Good point (I remember reading gram.y's
Neil Conway wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Couldn't we use SET only when we need to change the existing value?
I'm not sure what you mean. The pg_dump output will look like:
-- at the top of the dump
SET default_with_oids = false; -- or true, doesn't really matter
--
This patch adds a WITH / WITHOUT OIDS clause to CREATE TABLE
AS. This allows the user to explicitly specify whether OIDs should be
included in the newly-created relation (if form of this clause is
specified, the default_with_oids configuration variable is used). This
is useful because it provides
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
Bruce Momjian [EMAIL PROTECTED] writes:
Does this deal with the fact we now emit WITH/WITHOUT OID in
pg_dump?
No, that is an unrelated issue. I took a brief look at implementing
this over the break, but I couldn't see an easy way to do it properly:
if we pick a particular default for the GUC
Neil Conway wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Does this deal with the fact we now emit WITH/WITHOUT OID in
pg_dump?
No, that is an unrelated issue. I took a brief look at implementing
this over the break, but I couldn't see an easy way to do it properly:
if we pick a
Bruce Momjian [EMAIL PROTECTED] writes:
Couldn't we use SET only when we need to change the existing value?
I'm not sure what you mean. The pg_dump output will look like:
-- at the top of the dump
SET default_with_oids = false; -- or true, doesn't really matter
-- for a table that doesn't have
