Re: No exceptions?

Bob Badour wrote:
> paul c wrote:
>

>> paul c 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.
>>>> ...
>>
>> I suppose my "logic", if I may call it that, went like this (at 
>> evaluation time):
>>
>> 1) according to syntax, x must be a relation

>> 2) according to the catalogue, there are no attributes for a relation 
>> named x, so given that the syntax insists x is a relation, it must be 
>> the same relation as either TABLE_DEE or TABLE_DUM

For notational reasons only, if I give a name to the relation 'x = 1', say z, then I would say instead that if x is projected out of z, z is a boolean assertion. However, in my example 'x join y', I don't see that projection comes into play.

Assuming a db language admits a statement like 'SELECT y WHERE x = 1;' and we treat the restriction 'x = 1' as a relation I think that is the same as "'x = 1' join y" and we have stated something different from 'x join y'.

My understanding of the CWA in practice is that by convention we record all true facts and we don't record false facts, in TTM style, we might record z by saying 'z := <x,sometype,1>', if we knew just exactly what 'sometype' stood for - it could stand any of many types, eg. integer, string or even relation so it's not clear how to record it. But I would prefer to not load up the word 'record' with any special meaning such as 'write to disk' and simply say that "the relation 'x = 1'" exists if it has been stated. I think this is what I mean by syntax. Because 'sometype' has many possible values, I would say that 'x = 1' is not a relation that exists in many different forms or representations, rather it is many different relations even though I expect some people will find this statement controversial as far as a practical dbms is concerned!

I would say that TTM deals with this in its formal definitions by limiting the relations that the fundamental operators can use, eg., for <OR> on page a.13 of the 3rd edition's Appendix A which Hugh Darwen has generously made available at
http://www.dcs.warwick.ac.uk/~hugh/TTM/APPXA.pdf where it says "It is required that if <A,T1> is in Hr1 and <A,T2> is in Hr2, then T1 = T2".

One practical implication of TTM's definitions that I can think of is that evaluation of 'x <and> y' is not possible if x and y each have an attribute with the same name but different types, in other words closure isn't possible, hence if we insist on closure, we need runtime exceptions to avoid what is undefined. But I think the expression, ie., the syntax is possible. It also seems to me that in allowing a syntax such as 'y WHERE x = 1;', TTM is allowing a name (x) that has no specified type to have its type inferred from context - in this case I'd say the context comes from the definition of y, whatever that is. In this respect, I have a hard time understanding TTM, because while I happen to think of 'x = 1' as one representation of many relations, in TTM it seems to be a relation only in a context such as 'y WHERE x = 1'.   Is it illogical to explain away this context as an unwritten operation that chooses one from many possible relations? (To put it another way, in TTM an attribute is an ordered pair, the expression 'x = 1' by itself contains no such attribute.)

I'd like to explore this further wrt to my original question, but for now I think I've given enough for people to poke holes in.

p Received on Sun Jul 02 2006 - 21:35:10 CEST