Re: No exceptions?
From: paul c <toledobythesea_at_oohay.ac>
Date: Fri, 30 Jun 2006 22:41:30 GMT
Message-ID: <uMhpg.109181$iF6.52435_at_pd7tw2no>
>
> But then, what about expressions like "y minus x" where x is unknown?
> What if y and x were intended to both be very large relations with a
> small difference? The result would go from small to very large.
> ...
>
> Surprising results with no explanation are nowhere near as useful as an
> informative or even instructive error message.
Date: Fri, 30 Jun 2006 22:41:30 GMT
Message-ID: <uMhpg.109181$iF6.52435_at_pd7tw2no>
Bob Badour wrote:
> Jon Heggland wrote:
>
>> paul c wrote: >> >>> Let me re-phrase my original question: Is there a logical flaw in >>> substituting TABLE_DUM for x in the expression "x join y" when x is not >>> in the catalogue? >> >> I don't know what precisely you mean by "logical flaw", so I'll pass >> judgement. If something should be substituted for x (a "default value", >> so to speak), TABLE_DUM does seem the natural choice, though, as it >> corresponds to false/zero in some sense.
>
> But then, what about expressions like "y minus x" where x is unknown?
> What if y and x were intended to both be very large relations with a
> small difference? The result would go from small to very large.
> ...
Just to be clear, I assume that means (in TTM style):
y <AND> <NOT> TABLE_DUM ==
y <AND> TABLE_DEE ==
y
and yes it would be very large.
> Similarly for "not exists" expressions.
Yes.
>
>
>>> (Assuming that the syntax requires x to be a relation and with the whole >>> expression's value being TABLE_DUM as well and granting that such a >>> result might seem surprising to most people.) >> >> "TABLE_DUM join y" evaluates to the empty relation with y's heading, not >> TABLE_DUM (unless y's header is also empty, of course).
>
> Surprising results with no explanation are nowhere near as useful as an
> informative or even instructive error message.
No argument, I just don't want to handle that information in an evaluator, nor prescribe how it should be handled.
p Received on Sat Jul 01 2006 - 00:41:30 CEST