Re: Bug in ALTER COLUMN SET DATA TYPE ?

Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com> writes:
> On Sat, Nov 3, 2012 at 10:21 AM, Nikhil Sontakke <nikkhils(at)gmail(dot)com> wrote:
>>>> So coming back to the issue, do you think it's a good idea to teach
>>>> ATAddCheckConstraint() that the call is coming from a late phase of ALTER
>>>> TABLE ?

>>> +1

>> You mentioned AT_PASS_OLD_INDEX in your original mail, but I guess that
>> you meant that we should check for AT_PASS_OLD_CONSTR and then not raise
>> an error?

> Yeah, I meant AT_PASS_OLD_CONSTR.

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. The pass structure
has never meant anything for semantics of individual AlterTable actions;
it's only used to make sure those actions are done in an appropriate
order. Furthermore, the pass number isn't available where it would be
needed --- you'd have to pass it down through several levels of
subroutine that don't have another reason to care about it.

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.

regards, tom lane