From: | Noah Misch <noah(at)leadboat(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: ALTER TYPE 2: skip already-provable no-work rewrites |
Date: | 2011-01-24 05:08:06 |
Message-ID: | 20110124050806.GA15065@tornado.leadboat.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Jan 23, 2011 at 12:06:43PM -0500, Tom Lane wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> > On Sun, Jan 9, 2011 at 5:01 PM, Noah Misch <noah(at)leadboat(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Xiaobo Gu | 2011-01-24 05:17:21 | Re: [HACKERS] Is there a way to build PostgreSQL client libraries with MinGW |
Previous Message | Hitoshi Harada | 2011-01-24 04:42:28 | Re: REVIEW: PL/Python table functions |