Hi Alvaro
On Fri, Mar 28, 2008 at 6:05 PM, Alvaro Herrera <[EMAIL PROTECTED]>
wrote:
> NikhilS escribió:
>
> > I will take a look at the pg_dump related changes if you want. We will
> need
> > changes in flagInhAttrs() and in getTableAttrs() to query the backend
> for
> > these 2 attributes for p
On Fri, Mar 28, 2008 at 4:07 AM, NikhilS <[EMAIL PROTECTED]> wrote:
> Hi Alex,
>
>
> On Fri, Mar 28, 2008 at 4:58 AM, Alex Hunsaker <[EMAIL PROTECTED]> wrote:
> > Attached is a WIP patch I have been playing with in my spare time. It
> > should take care of the first 2. It does nothing for pg_dump
Hi Alex,
On Fri, Mar 28, 2008 at 4:58 AM, Alex Hunsaker <[EMAIL PROTECTED]> wrote:
> On Thu, Mar 27, 2008 at 5:14 AM, NikhilS <[EMAIL PROTECTED]> wrote:
> > * Add logic to disallow ADD CONSTRAINT ONLY to parent of an inheritance
> > hierarchy
> >
> > * Add logic to mark inherited constraints in t
NikhilS <[EMAIL PROTECTED]> writes:
> ...
> * Add logic to mark inherited constraints in the children:
> This can be achieved by introducing a new bool "coninherited" attribute in
> pg_constraint. This will be set to true on only those check constraints that
> are added to children via the inherita
NikhilS wrote:
Am important decision here is about adding a new attribute to pg_constraint
as it is the only sane way of determining inherited constraints, but that
will require an initdb. Comments?
There's no problem forcing an initdb at this point in the release cycle.
We will do that for su
Hi,
On Thu, Mar 20, 2008 at 7:36 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
>
> More to the point, it takes a capability away from the user without
> actually solving the problem we need to solve, namely to guarantee
> consistency between parent and child constraints. You can be sure
> that there i
