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

Re: [HACKERS] CHECK constraints inconsistencies

From: Bruno Wolff III <bruno(at)wolff(dot)to>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Michael Glaesemann <grzm(at)myrealbox(dot)com>,pgsql-bugs(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] CHECK constraints inconsistencies
Date: 2004-03-02 01:43:59
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugspgsql-hackers
On Mon, Mar 01, 2004 at 20:28:02 -0500,
  Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Michael Glaesemann <grzm(at)myrealbox(dot)com> writes:
> > In both cases, the CHECK constraint uses a function that is stable or 
> > volatile. It was suggested that functions used in CHECK constraints be 
> > restricted to immutable,
> This seems reasonable to me.  I'm a bit surprised we do not have such a
> check already.

There may be times you want to do this. For example you may want a timestamp
to be in the past. In this case as long as it was in the past when the
data was entered it will continue to be in the past (barring someone
resetting the system time). This is something someone might actually
check unlike comparing to random numbers.

I think just noting that check constraints are only checked on inserts
and updates and that this means that check constraints using volatile
or stable functions need to be well thought out.

In response to


pgsql-hackers by date

Next:From: Curt SampsonDate: 2004-03-02 01:52:52
Subject: Re: Check Constraints and pg_dump
Previous:From: Andrew DunstanDate: 2004-03-02 01:32:43
Subject: Re: log_line_info

pgsql-bugs by date

Next:From: Rod TaylorDate: 2004-03-02 02:25:01
Subject: Re: CHECK constraints inconsistencies
Previous:From: Tom LaneDate: 2004-03-02 01:28:02
Subject: Re: [HACKERS] CHECK constraints inconsistencies

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