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

Re: inconsistent comparison of CHECK constraints

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: inconsistent comparison of CHECK constraints
Date: 2012-01-16 22:48:47
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Excerpts from Tom Lane's message of lun ene 16 12:44:57 -0300 2012:
> Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> writes:
> > 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:
> >         if (equal(expr, stringToNode(TextDatumGetCString(val))))
> > So plain string comparison of the node's string representation.
> No, that's *not* a "plain string comparison", and if it were it would be
> wrong.  This is doing equal() on the node trees, which is in fact the
> correct implementation.

Aha, that makes sense.

> > MergeConstraintsIntoExisting is instead doing this:
> >     if (acon->condeferrable != bcon->condeferrable ||
> >         acon->condeferred != bcon->condeferred ||
> >         strcmp(decompile_conbin(a, tupleDesc),
> >                decompile_conbin(b, tupleDesc)) != 0)
> That's kind of a crock, but it's necessary because it's trying to detect
> equivalence of constraint expressions belonging to different tables,
> which could have different physical column numbers as noted by the
> comment.  So I don't see a way to reduce it to a simple equal().
> But for constraints applicable to just one table, equal() should be
> preferred as it's simpler and more reliable.

It makes plenty of sense too.

I've left the two separate implementations alone.

Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

In response to

pgsql-hackers by date

Next:From: Scott MeadDate: 2012-01-16 23:10:01
Subject: Re: IDLE in transaction introspection
Previous:From: Alvaro HerreraDate: 2012-01-16 22:40:38
Subject: Re: automating CF submissions (was xlog location arithmetic)

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