On Sun, Jan 23, 2011 at 12:06:43PM -0500, Tom Lane wrote: > Robert Haas <robertmh...@gmail.com> writes: > > On Sun, Jan 9, 2011 at 5:01 PM, Noah Misch <n...@leadboat.com> wrote: > >> As unintended fallout, it's no longer an error to add oids or a column > >> with a > >> default value to a table whose rowtype is used in columns elsewhere. This > >> seems > >> best. Defaults on the origin table do not even apply to new inserts into > >> such a > >> column, and the rowtype does not gain an OID column via its table. > > > I think this should be split into two patches (we can discuss both on > > this thread, no need to start any new ones), one that implements just > > the above improvement and another that accomplishes the main purpose > > of the patch. > > I haven't been paying much attention to this thread, but I happened to > read the above, and quite frankly it scares the cr*p out of me. I don't > believe that Noah even begins to be qualified to understand the > implications of adding/removing an OID column, and I clearly remember > the non-obvious bugs we've had in the past from that. Before this goes > in I want to see a convincing explanation (not an unsupported assertion) > why this isn't going to re-introduce those old bugs.
Turns out that we do set HEAP_HASOID and allocate space for an OID in the composite-type datums. We don't actually assign an OID, and I can't see any way to read it from the composite. It seems most consistent with the verdict of commit 6d1e361 to continue rejecting these cases. Thanks for the heads-up. > I'm also pretty unclear on why it's a good idea to let uses of a rowtype > be different from the table on which it's allegedly based. To the > extent that the current behavior allows that, isn't that a bug rather > than a feature we should extend? >From the perspective of defining the behavior afresh, I'd agree. I haven't >seen any stirrings of actually implementing this, though. Like Robert, I'm doubting there's a user benefit from rejecting these cases in preparation for the day that they would actually require it. nm -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers