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

inconsistent comparison of CHECK constraints

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: inconsistent comparison of CHECK constraints
Date: 2012-01-16 15:23:52
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
While reviewing Nikhil Sontakke's fix for the inherited constraints open
item we have, I noticed that MergeWithExistingConstraint and
MergeConstraintsIntoExisting are using rather different mechanism to
compare equality of the constraint expressions; the former does this:

        Datum        val;
        bool        isnull;

        val = fastgetattr(tup,
                          conDesc->rd_att, &isnull);
        if (isnull)
            elog(ERROR, "null conbin for rel %s",
        if (equal(expr, stringToNode(TextDatumGetCString(val))))
            found = true;

So plain string comparison of the node's string representation.

MergeConstraintsIntoExisting is instead doing this:

    if (acon->condeferrable != bcon->condeferrable ||
        acon->condeferred != bcon->condeferred ||
        strcmp(decompile_conbin(a, tupleDesc),
               decompile_conbin(b, tupleDesc)) != 0)

where decompile_conbin is defined roughly as

    expr = DirectFunctionCall2(pg_get_expr, attr,
    return TextDatumGetCString(expr);

So it is first decompiling the node into its source representation, then
comparing that.

Do we care about this?  If so, which version is preferrable?

I also noticed that MergeConstraintsIntoExisting is doing a scan on
conrelid and then manually filtering for conname, which seems worse than
the other code that's just using conname/connamespace as scankey.  This
is probably better on tables with tons of constraints.

Álvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>


pgsql-hackers by date

Next:From: Tom LaneDate: 2012-01-16 15:27:03
Subject: Re: age(xid) on hot standby
Previous:From: Robert HaasDate: 2012-01-16 14:53:19
Subject: Re: Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers

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