Re: Review of patch renaming constraints
| От | Nikhil Sontakke |
|---|---|
| Тема | Re: Review of patch renaming constraints |
| Дата | |
| Msg-id | CANgU5ZdyG-3wS13Xcea8m23E-v+mKxeJsrYFVAQVNxVdsr+KSw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Review of patch renaming constraints (Peter Eisentraut <peter_e@gmx.net>) |
| Ответы |
Re: Review of patch renaming constraints
|
| Список | pgsql-hackers |
> And primary keys are anyways not inherited. So why is the conisonlyIn the past, each kind of constraint was either always inherited or
> field interfering in rename? Seems quite orthogonal to me.
always not, implicitly. Now, for check constraints we can choose what
we want, and in the future, perhaps we will want to choose for primary
keys as well. So having conisonly is really a good step into that
future, and we should use it uniformly.
Anyways, fail to see the direct connection between this and renaming. Might have to look at this patch for that.
Regards,
Nikhils
В списке pgsql-hackers по дате отправления: