"Gauthier, Dave" <dave.gauthier@xxxxxxxxx> 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 (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
