Skip site navigation (1) Skip section navigation (2)

Re: Bug in ALTER COLUMN SET DATA TYPE ?

From: Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Nikhil Sontakke <nikkhils(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Bug in ALTER COLUMN SET DATA TYPE ?
Date: 2012-11-05 09:12:42
Message-ID: CABOikdPzwimryLtnN52arpMAuLL7NBfSAY0XHpNzCcM3nWrdEQ@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Mon, Nov 5, 2012 at 4:41 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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: alter-type-readd-constraint.patch
Description: application/octet-stream (5.4 KB)

In response to

Responses

pgsql-hackers by date

Next:From: Magnus HaganderDate: 2012-11-05 09:24:02
Subject: Re: Fwd: Stalled post to pgsql-hackers
Previous:From: Etsuro FujitaDate: 2012-11-05 03:52:06
Subject: Update obsolete text in indexam.sgml

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group