Re: Review: Non-inheritable check constraints - Mailing list pgsql-hackers

From Nikhil Sontakke
Subject Re: Review: Non-inheritable check constraints
Date
Msg-id CANgU5ZfKnj5537PVs1EiY+Mdz8zBj-8pN-viRYX6EMNWGS39Zg@mail.gmail.com
Whole thread Raw
In response to Re: Review: Non-inheritable check constraints  (Alex Hunsaker <badalex@gmail.com>)
Responses Re: Review: Non-inheritable check constraints
List pgsql-hackers
Hi Alex, <br /><br />I guess we both are in agreement with each other :) <br /><br />After sleeping over it, I think
thatcheck is indeed dead code with this new non-inheritable check constraints functionality in place. So unless you
havesome other comments, we can mark this as 'Ready for Commiter'. <br /><br />Again, thanks for the thorough review
andsubsequent changes!<br /><br />Regards,<br />Nikhils <br /><br /><div class="gmail_quote">On Fri, Oct 7, 2011 at
12:18PM, Alex Hunsaker <span dir="ltr"><<a href="mailto:badalex@gmail.com">badalex@gmail.com</a>></span>
wrote:<br/><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div
class="im">OnFri, Oct 7, 2011 at 00:28, Nikhil Sontakke <<a
href="mailto:nikkhils@gmail.com">nikkhils@gmail.com</a>>wrote:<br /> > Hi Alex,<br /><br /></div><div
class="im">>>So with it all spelled out now I see the "constraint must be added to<br /> >> child tables
too"check is dead code.<br /> >><br /> ><br /> > Thanks the above step-wise explanation helps.<br />
><br/> > But AFAICS, the default inhOpt value can be governed by the SQL_inheritance<br /> > guc too. So in
thatcase, it's possible that recurse is false and child<br /> > tables are present, no?<br /><br /></div>Well... Do
wereally want to differentiate between those two case? I<br /> would argue no.<br /><br /> Given that:<br />  set
sql_inhertanceto off;<br />  alter table xxx alter column;<br /> behaves the same as<br />  set sql_inhertance to
on;<br/>  alter table only xxx alter column;<br /><br /> Why should we treat constraints differently? Or put another
wayif set<br /> sql_inhertance off makes alter table behave with an implicit only,<br /> shouldn't add/drop constraint
respectthat?<br /><div class="im"><br /> > Infact as I now remember, the reason my patch was looping through was
to<br/> > handle this very case. It was based on the assumptions that some constraints<br /> > might be ONLY type
andsome can be inheritable.<br /> > Although admittedly the current ALTER TABLE functionality does not allow
this.<br/><br /></div>Hrm... Ill I see is a user who turned off sql_inhertance wondering why<br /> they have to specify
ONLYon some alter table commands and not others.<br /> I think if we want to support "ONLY" constraint types in the way
you<br/> are thinking about them, we need to put ONLY some place else (alter<br /> table xxx add only constraint ?).
PersonallyI don't see a reason to<br /> have that kind of constraint. Mostly because I don't see how its<br />
functionallydifferent. Is it somehow?<br /><br /> Anyone else have any thoughts on this?<br /></blockquote></div><br /> 

pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: [OT?] Time-zone database down [was: Re: timezone buglet?]
Next
From: Robert Haas
Date:
Subject: Re: [PATCH] Fix little typo in docs in func.sgml