Re: Review: Non-inheritable check constraints

Hi Alex,

I guess we both are in agreement with each other :)

After sleeping over it, I think that check is indeed dead code with this new
non-inheritable check constraints functionality in place. So unless you have
some other comments, we can mark this as 'Ready for Commiter'.

Again, thanks for the thorough review and subsequent changes!

Regards,
Nikhils

On Fri, Oct 7, 2011 at 12:18 PM, Alex Hunsaker <badalex(at)gmail(dot)com> wrote:

> On Fri, Oct 7, 2011 at 00:28, Nikhil Sontakke <nikkhils(at)gmail(dot)com> wrote:
> > Hi Alex,
>
> >> So with it all spelled out now I see the "constraint must be added to
> >> child tables too" check is dead code.
> >>
> >
> > Thanks the above step-wise explanation helps.
> >
> > But AFAICS, the default inhOpt value can be governed by the
> SQL_inheritance
> > guc too. So in that case, it's possible that recurse is false and child
> > tables are present, no?
>
> Well... Do we really want to differentiate between those two case? I
> would argue no.
>
> Given that:
> set sql_inhertance to off;
> alter table xxx alter column;
> behaves the same as
> set sql_inhertance to on;
> alter table only xxx alter column;
>
> Why should we treat constraints differently? Or put another way if set
> sql_inhertance off makes alter table behave with an implicit only,
> shouldn't add/drop constraint respect that?
>
> > Infact as I now remember, the reason my patch was looping through was to
> > handle this very case. It was based on the assumptions that some
> constraints
> > might be ONLY type and some can be inheritable.
> > Although admittedly the current ALTER TABLE functionality does not allow
> this.
>
> Hrm... Ill I see is a user who turned off sql_inhertance wondering why
> they have to specify ONLY on some alter table commands and not others.
> I think if we want to support "ONLY" constraint types in the way you
> are thinking about them, we need to put ONLY some place else (alter
> table xxx add only constraint ?). Personally I don't see a reason to
> have that kind of constraint. Mostly because I don't see how its
> functionally different. Is it somehow?
>
> Anyone else have any thoughts on this?
>