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).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.
Of course.
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 ;)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).
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
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
