Re: Bug in ALTER COLUMN SET DATA TYPE ? - Mailing list pgsql-hackers

From Pavan Deolasee
Subject Re: Bug in ALTER COLUMN SET DATA TYPE ?
Date
Msg-id CABOikdPzwimryLtnN52arpMAuLL7NBfSAY0XHpNzCcM3nWrdEQ@mail.gmail.com
Whole thread Raw
In response to Re: Bug in ALTER COLUMN SET DATA TYPE ?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Bug in ALTER COLUMN SET DATA TYPE ?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers

On Mon, Nov 5, 2012 at 4:41 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:


It's clear that we need to pass down the information that this action is
coming from re-creation of a check constraint, but I think the above
proposal for how to do it is pretty wrong-headed.

Yeah, I only meant that we need to teach ATExecAddConstraint that its being called from the specific pass of ALTER TABLE and wanted to get agreement on that. I hadn't thought about any particular implementation. So your proposal below looks absolutely fine and clean.
 

I'm inclined to think the cleanest solution is to add another value of
enum AlterTableType, perhaps "AT_ReAddConstraint", to signal that we're
executing a re-add; and then add another bool parameter to
ATExecAddConstraint to tell the latter not to complain if child tables
exist.  This is more in line with pre-existing coding choices such as
the use of AT_AddConstraintRecurse.

Please see attached patch which does what you suggested above. May be it needs a little more commentary to record why we made this specific change. Please let me know if you think so and want me to do that.

Thanks,
Pavan

Attachment

pgsql-hackers by date:

Previous
From: "Etsuro Fujita"
Date:
Subject: Update obsolete text in indexam.sgml
Next
From: Peter Eisentraut
Date:
Subject: Re: Synchronous commit not... synchronous?