Michael Glaesemann <grzm (AT) myrealbox (DOT) com> writes:
This seems reasonable to me. I'm a bit surprised we do not have such a
check already.

Of course, a user could easily get into the sort of situation you
describe anyway, just by lying about the volatility labeling of a
user-defined function. But at least we could say it was his fault
then ;-)

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

On Mon, Mar 01, 2004 at 20:28:02 -0500,
Tom Lane <tgl (AT) sss (DOT) pgh.pa.us> wrote:
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.

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Rod Taylor <pg (AT) rbt (DOT) ca> writes:
Yes. I was just arguing in a different thread that triggers are the
right way to express one-time checks. A constraint notionally expresses
an always-true condition. (The SQL spec defines this more formally as a
condition that must hold at the completion of every statement or every
transaction, depending on the "deferrability" property of the
constraint.) We presently support only constraints that are of a form
that need only be checked at row insert or update time. It would be
inconsistent with the spec to consider that part of the fundamental
semantics of check constraints, though --- it's just an implementation
restriction. Someday we might want to remove that restriction.

Requiring CHECK functions to be immutable is consistent with the
existing implementation restriction. Misusing them in the way Bruno
suggests is a cute trick, but I think we have to consider it to be
gaming the implementation, not a supported way to do things.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org