> 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.
Well, it certainly is reasonable to have better behavior than currently.
We do something now, which is at odds with the previous convention
(which also did something).
> A WITH/WITHOUT OIDS option on CREATE TABLE AS might be reasonable.
Of course.
> 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).
It is unfortunate that the optional-OIDs has this drawback; it perhaps
should have been more explicit in the initial discussions. But I'm
hearing about difficulties, not impossibilities, so that is encouraging ;)
What would be required to have OIDs for all SELECT/INTO product tables
for this release? That could fit into 7.3 and not break applications;
the current convention for this (that is, dropping OID characteristics)
might be characterized as an omission, not a choice.
- Thomas