Re: assertions and constraint triggers

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Marko Tiikkaja <marko(dot)tiikkaja(at)cs(dot)helsinki(dot)fi>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: assertions and constraint triggers
Date: 2010-08-11 15:49:43
Message-ID: 1281541783.26522.8.camel@vanquo.pezone.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On ons, 2010-08-11 at 10:47 -0400, Tom Lane wrote:
> > I thought the point of ASSERTIONs was that you could write a thing
> such as:
> > CREATE ASSERTION foo CHECK ((SELECT count(*) FROM tbl) = 4);
> > Enforcing that kind of constraints without true serializability
> seems
> > impractical.
>
> Enforcing that kind of constraint seems impractical with or without
> serializability. You need some optimization method that avoids the
> need
> to do full-table scans after every update, or it's not going to be
> useful for any real-world situation. Without a scheme that can do
> incremental checking for some useful class of assertion expressions,
> this isn't going to go far.

I'm not sure how great a use case there is for an assertion of the kind
"this table must contain at least 30 million rows". But I think there
are many uses cases for checks like that on small and rarely changing
tables.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2010-08-11 15:51:06 Re: Regression tests versus the buildfarm environment
Previous Message Tom Lane 2010-08-11 15:48:37 Re: Regression tests versus the buildfarm environment