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

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073