On Mon, Aug 27, 2012 at 1:34 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
> > Maybe, but in that case shouldn't referencing a system column chuck an
> error?
>
> Yeah, possibly. I think none of them are populated with anything useful
> during INSERT checks (though OID might be an exception?). Less sure
> about the state during UPDATE checks, though.
>
> My vote honestly would be to make it be an error. A check constraint
which fails only after it has been saved and then updated strikes me as
behavior outside the role of a check constraint and dangerously so. It
doesn't work as advertised, and people will find this out only after their
data is shown not to be consistent with the check constraint.
This being said, again, my sense is that no inherit check constraints will
make it quite unlikely that this will ever affect production servers. So
failing this it's sufficient I think in future versions (maybe 9.3 forward)
to add a paragraph to the docs. Something like:
Warning: The behavior of a check constraint operating against a system
column is undefined. Check constraints are not intended to be used this way
and behavior may change without notice.
Maybe worth bringing up on the docs list. I don't mind the fact that
behavior is undefined in some cases. However, it might be a good idea to
let people know that they are moving into "we won't commit not to breaking
your app even if you get this to work" territory.
Best Wishes,
Chris Travers