Greg Stark <stark(at)mit(dot)edu> writes:
> On Wed, Apr 25, 2012 at 4:06 PM, Kevin Grittner
> <Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
>> A CHECK constraint using a volatile function is potentially valid
>> and useful, IMO.
> Hm. I suppose it depends on what you think a constraint is. I had
> always thought it was a guarantee that all the data in the table would
> meet that constraint. Not just a procedural definition for something
> to do at certain points in time.
Well, it's a guarantee that the expression evaluated to "true" at the
time of insertion or update of every row. If you confine your attention
to immutable expressions then you can presume that the expression is
true for every row in the table at any time; but I'm with Kevin that
there are reasonable use-cases that don't fit into that.
> Hm, but this does raise the question of whether they're the right
> thing to be basing the partitioning constraint exclusion code on.
As long as we only consider expressions that are immutable as usable
partition constraints, that's not a problem.
> speculate without checking again that we check the immutability of the
> constraint before using it in constraint exclusion but that seems a
We do, and I don't see why that's ad-hoc. In general the planner has to
check the volatility status of any expression it's going to try to
regards, tom lane
In response to
pgsql-bugs by date
|Next:||From: Tom Lane||Date: 2012-04-25 17:54:16|
|Subject: Re: BUG #6602: concurrent psql session clobbers history |
|Previous:||From: Greg Stark||Date: 2012-04-25 15:48:45|
|Subject: Re: BUG #6612: Functions can be called inside CHECK statements|