I'm discovering that I need to write quite a few functions for use strictly w/ check constraints and I'm wondering if declaring the volatility category for said functions will affect their behavior when invoked by PostgreSQL's check constraint mechanism.
Adrian's point is spot-on but the important thing to consider in this situation is that check constraints are assumed to be immutable and if you implement a check function that is not you don't get to complain what you see something broken. The nature and use of an immutable check constraint only has a single dynamic - execute the function using the given values once for every record INSERT or UPDATE. There is no reason, and I suspect there is no actual, attempt to even look at the volatility category of said function before performing those actions. It is possible that two records inserted or updated in the same query could make use of the caching possibilities afforded by immutable functions but if so assume it is being done unconditionally.
David J.
Your point about ".. check constraints are assumed to be immutable ..", is that in the manual? Because I don't remember reading it in the constraints section, nor in the volatility categories section, nor in the server programming sections. Granted, I haven't read the whole manual yet nor do I have what I've read so far memorized, but I think that little fact would have struck a cord in my gray matter. So if you can point me to the spot in the manual where this is covered I would appreciate it.
