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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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 Content-Type Size
alter-type-readd-constraint.patch application/octet-stream 5.4 KB

In response to

Responses

Browse pgsql-hackers by date

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