Re: ALTER TYPE 2: skip already-provable no-work rewrites - Mailing list pgsql-hackers

From Robert Haas
Subject Re: ALTER TYPE 2: skip already-provable no-work rewrites
Date
Msg-id AANLkTi=bic=UsrObt7wHW2vw6Gpb4eHbtzhWcgu8zYRm@mail.gmail.com
Whole thread Raw
In response to Re: ALTER TYPE 2: skip already-provable no-work rewrites  (Noah Misch <noah@leadboat.com>)
Responses Re: ALTER TYPE 2: skip already-provable no-work rewrites  (Noah Misch <noah@leadboat.com>)
List pgsql-hackers
On Mon, Jan 24, 2011 at 7:10 PM, Noah Misch <noah@leadboat.com> wrote:
> * at1.1-default-composite.patch
> Remove the error when the user adds a column with a default value to a table
> whose rowtype is used in a column elsewhere.

Can we fix this without moving the logic around quite so much?  I'm
worried that could introduce bugs.

It strikes me that the root of the problem here is that this test is
subtly wrong:

        if (newrel)
                find_composite_type_dependencies(oldrel->rd_rel->reltype,

          RelationGetRelationName(oldrel),

          NULL);

So what this is saying is: If the user has performed an operation that
requires a rewrite, then we can't carry out that operation if the
rowtype is used elsewhere, because we wouldn't be able to propagate
the rewrite to those other objects.  That's correct, unless the
operation in question is one which isn't supported by composite types
anyway.  We trigger a rewrite if there is a has-OIDs change or if
tab->newvals contains any elements, which can happen if either there
is a type change or if a column with a default is added.  So it seems
to me that we could fix this with something like the attached.
Thoughts?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Attachment

pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: SSL Client Certificate pass phrases
Next
From: Robert Haas
Date:
Subject: Re: ALTER TYPE 2: skip already-provable no-work rewrites