> It seems hard to believe that ATExecDropConstraint() doesn't need any
> adjustment.
>
>
Yeah, I think we could return early on for "only" type of constraints.

Also, shouldn't the systable scan break out of the while loop after a
matching constraint name has been found? As of now, it's doing a full scan
of all the constraints for the given relation.

> @@ -6755,6 +6765,7 @@ ATExecDropConstraint(Relation rel, const char
*constrName,
>      HeapTuple    tuple;
>      bool        found = false;
>      bool        is_check_constraint = false;
> +    bool        is_only_constraint = false;
>
>      /* At top level, permission check was done in ATPrepCmd, else do it
*/
>      if (recursing)
> @@ -6791,6 +6802,12 @@ ATExecDropConstraint(Relation rel, const char
*constrName,
>          /* Right now only CHECK constraints can be inherited */
>          if (con->contype == CONSTRAINT_CHECK)
>              is_check_constraint = true;
> +
> +        if (con->conisonly)
> +        {
> +            Assert(is_check_constraint);
> +            is_only_constraint = true;
> +        }
>
>          /*
>           * Perform the actual constraint deletion
> @@ -6802,6 +6819,9 @@ ATExecDropConstraint(Relation rel, const char
*constrName,
>          performDeletion(&conobj, behavior);
>
>          found = true;
> +
> +        /* constraint found - break from the while loop now */
> +        break;
>      }
>
>      systable_endscan(scan);
> @@ -6830,7 +6850,7 @@ ATExecDropConstraint(Relation rel, const char
*constrName,
>       * routines, we have to do this one level of recursion at a time; we
can't
>       * use find_all_inheritors to do it in one pass.
>       */
> -    if (is_check_constraint)
> +    if (is_check_constraint && !is_only_constraint)
>          children = find_inheritance_children(RelationGetRelid(rel),
lockmode);
>      else
>          children = NIL;

PFA, revised version containing the above changes based on Alvaro's v4
patch.

Regards,
Nikhils

Attachment: non_inh_check_v5.0.patch
Description: Binary data

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to