"Gauthier, Dave" <[email protected]> writes:
> I believe I can "set constraints" to achieve the same thing?
No, you can't. There are no deferrable check constraints in Postgres.
> I just don't want the check to happen until commit time. The users may make
> many row changes, the later ones "fixing" what the earlier ones would
> otherwise flag as problematic with the check.
Even if it would work, this design implies holding a transaction open
over multiple user interactions, possibly including lunch breaks or
what-have-you. That's a really bad idea for a number of reasons (see
the archives for elucidation, but locks and vacuum are the key reasons
to avoid very-long-running transactions). You might consider instead
holding the work-in-progress rows in a temporary table, or something
like that.
If you're really desperate to do it that way, you could consider
testing the conditions in a deferred "constraint trigger" instead of
using CHECK. But I think you'll find yourself redesigning the system
as soon as you get it into production.
regards, tom lane
--
Sent via pgsql-general mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
