Re: Review: Non-inheritable check constraints

On Fri, Oct 7, 2011 at 00:28, Nikhil Sontakke <nikkhils@gmail.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?