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

Re: Check constraints on non-immutable keys

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Magnus Hagander <magnus(at)hagander(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Check constraints on non-immutable keys
Date: 2010-06-30 17:16:15
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Wed, Jun 30, 2010 at 11:49 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I can't recall many
>> field complaints about it. And the ones I do recall wouldn't have been
>> prevented by a check as stupid as "are there immutable functions in
>> here".

> Hopefully there aren't too many ways to get data into a table that
> doesn't satisfy its check constraint - what else are you thinking of?

Nobody is talking about having bypassed a check constraint --- the
problem here is what if the "same" constraint condition is true today
and false tomorrow.  The cases that I can recall were not directly about
time passing, but rather about check constraints that were designed to
examine the contents of other tables or other rows in the same table.
Functions that do that are properly declared STABLE not VOLATILE, but
they'd still be rejected by Magnus' proposed restriction.  The problem
is that people would be *very* likely to just mark them IMMUTABLE rather
than understand that what they're trying is fundamentally unreliable.
That would cause them other problems, and they'd still be at risk of
their dumps not reloading.

I concur with the thought that the most useful solution might be a way
to tell pg_restore to remove or disable check constraints.

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Richard HuxtonDate: 2010-06-30 17:17:50
Subject: Re: Check constraints on non-immutable keys
Previous:From: Bruce MomjianDate: 2010-06-30 17:15:57
Subject: Re: 9.0beta2 - server crash when using HS + SR

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