On Thu, Feb 17, 2005 at 11:03:58AM -0700, Michael Fuhr wrote: > On Thu, Feb 17, 2005 at 04:37:43PM +0100, Wolfgang Drotschmann wrote: > > > "...CHECK expressions cannot contain subqueries nor refer to > > variables other than VALUE." > > In experiments I've defined a domain's CHECK expression to call a > function that makes queries. It worked in simple tests; I don't > know if it'll work in the general case. The problem is basically that modifying a table elsewhere could have the effect of invalidating the entries in the table being checked. So while having the CHECK constraint call a function will work, it will not guarentee that it will be checked whenever the result of the subquery changes. The simplest example I can think of would be: CREATE TABLE blah ( ... field INT4 CHECK( field > (SELECT value FROM configtable WHERE key = 'field_limit') ), ... ); If you hide the comparison within a function PostgreSQL will let you, but it won't guarentee that it will always be true. For example, if you modify the configtable you could invalidate the constraint for many rows at once, yet PostgreSQL has no way of knowing that. This case is simple but as the subqueries become more complex, it gets harder to see a shortcut. Eventually you'd have to resort to rechecking every row of table blah every time any query modifies any dependant table. Hope this helps, -- Martijn van Oosterhout <kleptog@xxxxxxxxx> http://svana.org/kleptog/ > Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a > tool for doing 5% of the work and then sitting around waiting for someone > else to do the other 95% so you can sue them.
Attachment:
pgp5cHoxM9KmM.pgp
Description: PGP signature
