> The current svn trunk (to be 1.3) does. So how far do you take this? I've been playing around with plpgsql a bit and am pretty encouraged by what I'm discovering; now I'm at a point where I'm thinking, "how far do/can I go with this?" Probably the best example is input validation. Constraints and triggers on the database will (or at least should) prevent bad data from being added to the database, but the UI generally needs to provide more informative messages than errors thrown by the database, and provide errors messages for every invalid field, whereas the database will fail/stop on the first error. Consequently, I find that much of the data logic ends up being duplicated outside of the database to enhance the user experience. Might there be a way to move these validation routines into the database as well, and unify all the data logic into one place? > > Yes, but I'd implement the constraint "all transactions must balance" as > > a trigger that fires when the transaction is complete. This would > > enforce data integrity regardless of whether or not the database API is > > used, which I think is also important. > > That's problematic to do in PostgreSQL because statement-level > triggers don't have access to statement args, and I don't believe they > can be deferred. In another email I did provide a simple example of how I might implement this; I don't know if you saw it. Of course, that assumes your database isn't designed by .... :-) Karl Nack Futurity, Inc 5121 N Ravenswood Ave Chicago, IL 60640 773-506-2007 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
