Re: Problem identifying constraints which should not be inherited
От | NikhilS |
---|---|
Тема | Re: Problem identifying constraints which should not be inherited |
Дата | |
Msg-id | d3c4af540803200625s6904e31fw4275aa73770cb417@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Problem identifying constraints which should not be inherited (Alvaro Herrera <alvherre@commandprompt.com>) |
Список | pgsql-bugs |
Hi, On Thu, Mar 20, 2008 at 6:11 PM, Alvaro Herrera <alvherre@commandprompt.com> wrote: > NikhilS escribi=F3: > > > On Wed, Mar 19, 2008 at 8:23 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > > > If it's a small patch, it's wrong by definition. AFAICS there is no > way > > > to fix this correctly that doesn't involve catalog changes. The point > > > of the TODO is that you have to enforce that the inherited constraint > > > sticks around, eg can't be dropped on a child table while it's still > > > present on the parent. There are implications for pg_dump too. > > > > Ok, I understand. But even then this could patch could be considered > even if > > it does not solve the TODO completely, no? It atleast disallows ONLY ADD > > CONSTRAINT on the parent. > > No, because you would then feel that the TODO item is completed and not > provide a patch for the whole problem :-) > :) Guess, I should have been wordier in my earlier response and should have mentioned: "This patch, if acceptable can be considered as a small step towards the TODO" too. Regards, Nikhils --=20 EnterpriseDB http://www.enterprisedb.com
В списке pgsql-bugs по дате отправления: