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.
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 |