Re: change in behaviour? Is this a regression in function?

Tom Lane wrote:
> 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.

I don't have a problem with making no oids the default.  I just think
CREATE TABLE and CREATE TABLE AS should behave similarly in terms of
oids.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073