On 9/1/06, Alvaro Herrera <alvherre@commandprompt.com> wrote:
> Bernd Helmle wrote:
>
> > <tgl@sss.pgh.pa.us> 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
