Neil Conway <neilc@samurai.com> writes:
> Unless we can define some consistent semantics for when we use the
> hasoids of the source table(s), I'd say we should just add the
> WITH/WITHOUT OIDS syntax.
I agree with Neil: in many situations it's not reasonable to try to
associate a unique "source table" with a CREATE AS or SELECT INTO, and
therefore automatically propagating hasoids is doomed to failure.
A WITH/WITHOUT OIDS option on CREATE TABLE AS might be reasonable.
There are implementation gotchas to worry about. The reason the
behavior changed in 7.3 is that with the new OIDS-are-optional tuple
header layout, the top level plan node's tupdesc *must* have the correct
hasoids setting, and it turned out to be too difficult to back-patch
this decision into an already-built plan tree. It's hard even to get it
to work for INSERT/UPDATE (see the notes in ExecAssignResultTypeFromTL),
and SELECT INTO is such a wart on the side of the system that that
solution doesn't work for it (see the notes in InitPlan). This area
could use some rethinking in 7.4 (too late to mess with it for 7.3
though).
Someday it would be worth restructuring CREATE AS/SELECT INTO so that
they internally look like INSERT ... SELECT rather than a warty version
of SELECT. (But INSERT ... SELECT is pretty warty itself; someday we
need to fix the querytree structure so that there's not a forced
one-to-one relationship between targetlists and rangetables. INSERT
... SELECT would really prefer to have two tlists and only one rtable.)
regards, tom lane
