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. 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? >> # The fact that ALTER TYPE requires rewriting the whole table is >> sometimes an advantage, because the rewriting process >> # eliminates any dead space in the table. > I'm not sure what we can recommend here instead. New-style VACUUM FULL. I don't think that a patch that makes it harder to use ALTER TABLE this way is a problem in itself, now that we've got that. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers