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
