Re: Check constraints on non-immutable keys - Mailing list pgsql-hackers

From Merlin Moncure
Subject Re: Check constraints on non-immutable keys
Date
Msg-id AANLkTimjcTlahvW08UuxdnZV9SaUZm1TwdjVdQl1IyCd@mail.gmail.com
Whole thread Raw
In response to Check constraints on non-immutable keys  (Magnus Hagander <magnus@hagander.net>)
List pgsql-hackers
On Wed, Jun 30, 2010 at 9:47 AM, Magnus Hagander <magnus@hagander.net> wrote:
> We currently allow this:
>
> postgres=# create table t(a timestamptz not null primary key, check(a > now()));
> NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index
> "t_pkey" for table "t"
> CREATE TABLE
>
>
> Which seems very wrong. For one thing, a dump of this database can not
> be restored if now() has advanced enough into the future (which it
> will eventually). It also makes impossible to do things like SET a=a
> on the table.
>
> Yes, this is clearly a stupidly defined constraint, but why do we allow it?
>
> Shouldn't we disallow anything that's not IMMUTABLE in a check constraint?

suppose you did do this: shouldn't you then also recheck the
constraint if the function is create/replaced?

merlin


pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: Check constraints on non-immutable keys
Next
From: Tom Lane
Date:
Subject: Re: Check constraints on non-immutable keys