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 post 80300
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 the children:
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 or set
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 is
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
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 inheritance
