Re: Review: Non-inheritable check constraints
От | Nikhil Sontakke |
---|---|
Тема | Re: Review: Non-inheritable check constraints |
Дата | |
Msg-id | CANgU5ZfKnj5537PVs1EiY+Mdz8zBj-8pN-viRYX6EMNWGS39Zg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Review: Non-inheritable check constraints (Alex Hunsaker <badalex@gmail.com>) |
Ответы |
Re: Review: Non-inheritable check constraints
|
Список | 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 по дате отправления: