Skip site navigation (1) Skip section navigation (2)

Re: Review: Non-inheritable check constraints

From: Nikhil Sontakke <nikkhils(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Alex Hunsaker <badalex(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Review: Non-inheritable check constraints
Date: 2011-12-04 07:22:56
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
> I had a look at this patch today.  The pg_dump bits conflict with
> another patch I committed a few days ago, so I'm about to merge them.
> I have one question which is about this hunk:
Thanks for taking a look Alvaro.

> @@ -2312,6 +2317,11 @@ MergeWithExistingConstraint(Relation rel, char
> *ccname, Node *expr,
>                con->conislocal = true;
>            else
>                con->coninhcount++;
> +           if (is_only)
> +           {
> +               Assert(is_local);
> +               con->conisonly = true;
> +           }
>            simple_heap_update(conDesc, &tup->t_self, tup);
>            CatalogUpdateIndexes(conDesc, tup);
>            break;
> Is it okay to modify an existing constraint to mark it as "only", even
> if it was originally inheritable?  This is not clear to me.  Maybe the
> safest course of action is to raise an error.  Or maybe I'm misreading
> what it does (because I haven't compiled it yet).
Hmmm, good question. IIRC, the patch will pass is_only as true only if it
going to be a locally defined, non-inheritable constraint. So I went by the
logic that since it was ok to merge and mark a constraint as locally
defined, it should be ok to mark it non-inheritable from this moment on
with that new local definition?



In response to


pgsql-hackers by date

Next:From: Pavel StehuleDate: 2011-12-04 07:40:31
Subject: planner fails on HEAD
Previous:From: Tom LaneDate: 2011-12-04 04:19:54
Subject: Re: cannot read pg_class without having selected a database / is this a bug?

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group