Bruce Momjian <pgman@candle.pha.pa.us> writes:
> I find it uneven for CREATE TABLE AS not to have oids, while CREATE
> TABLE does. Was the problem that we had multiple tables in the query,
> and some may have oids and some not, and we didn't know if we should
> create an oid column?
No, the reason for the change in behavior was strictly an implementation
problem. Because of the new OIDs-are-optional tuple header layout, the
plan tree has to be built with an awareness of whether it's supposed to
produce tuples with or without space for an OID.
Now that I look at it again, there's a relatively simple solution after
all: we could add a field to EState indicating that we're doing a SELECT
INTO, which InitPlan could set before starting the plan tree
initialization. Then ExecAssignResultTypeFromTL could look at that to
help it decide what to do. (Annoying how the solution is only obvious
months after the fact ...)
So I guess the question at this point is do we want to flip-flop the
behavior yet again, or leave well enough alone? I don't think that the
fact that the behavior changed is sufficient reason to label the new
behavior a bug; there are people who like it this way (see original
discussion back in September). See also recent discussions about
changing the default behavior of CREATE TABLE to not include OIDs.
regards, tom lane
