On Sun, Jan 23, 2011 at 12:06 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Sun, Jan 9, 2011 at 5:01 PM, Noah Misch <noah@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.
Because all of our old bugs now have regression tests that will break
if we reintroduce them?
I guess that probably falls into the category of "wishful thinking".
> 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?
It's not clear to me what it would mean for OIDs or default values to
propagate themselves to the table's row type. Check constraints,
foreign keys, unique constraints, etc. don't either. In fact, not
even the NOT NULL property flows through. On the surface, preventing
these details from interfering with ALTER TABLE commands that can't
actually break anything seems like removing an annoying implementation
restriction, but I guess one could make the argument that we actually
intend to make those flow through some day. But if so, this is the
first I'm hearing of it.
>>> # 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.
Cool. That'll reclaim space from dropped columns and stuff?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
