At 11:45 29/09/00 -0700, Stephan Szabo wrote:
>On Fri, 29 Sep 2000, Philip Warner wrote:
>
>> At 01:53 29/09/00 -0400, Tom Lane wrote:
>> >
>> >The canonical example is a check like
>> > CHECK (mycol > (SELECT max(othertab.othercol) FROM othertab))
>> >declared as a constraint on mytab.
>>
>> I would argue that a CHECK constraint only applies to the table on which it
>> is defined - basically a contract to ensure that certain conditions apply
>> to changes on that table.
>
>The problem is that the spec seems to say that constraints
>are checked either at end of transaction or statement
>and doesn't seem to say anything about limiting which statements
You're quite right; my (weak) argument was that since we are already
breaking the spec by allowing arbitrary functions, we should either
strengthen our conformance to the spec (by disallowing arbitrary
functions), or allow statements inside CHECK constraints (since they are
there already via functions), and ignore the consequences in other tables
(as we currently do with functions).
----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.B.N. 75 008 659 498) | /(@) ______---_
Tel: (+61) 0500 83 82 81 | _________ \
Fax: (+61) 0500 83 82 82 | ___________ |
Http://www.rhyme.com.au | / \|
| --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/
