On 9/1/06, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
Bernd Helmle wrote:
> <[EMAIL PROTECTED]> wrote:
> >* It's too early in the morning for me to be clear about the difference
> >between CASCADED and LOCAL CHECK OPTION --- I think that this would
> >merely alter the set of check constraints collected for a particular
> >query, but if there's something more fundamental there, this scheme
> >might not work at all. So look into that first.
>
> LOCAL checks the data to be updated against its own view WHERE
> condition only, where CASCADED involves all WHERE conditions of all
> underlying views.
I don't understand this part very well. Say if you have a view WITH
CHECK OPTION whose condition is "foo > 5", and then define a view WITH
LOCAL CHECK OPTION on top of that, whose condition is "bar > 5". Does
the local check option on the second view that I can insert a row with
foo=4, bar=6? That doesn't violate the condition of bar > 5, so it
yes. or at least that's the way i read that...
seems fine to me. But it also seems quite idiotic because it violated
the original foo>5 condition.
and that means that without the CHECK OPTION constraint you can insert
anything into the base table no matter what the WHERE condition in the
view is...
again, this is the way informix implements it...
ahhh, the great members of the SQL COMITTEE...
--
regards,
Jaime Casanova
"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs and the universe trying
to produce bigger and better idiots.
So far, the universe is winning."
Richard Cook
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
