Re: No exceptions?

From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Fri, 30 Jun 2006 01:24:12 GMT
Message-ID: <03%og.3948$pu3.94371@ursa-nb00s0.nbnet.nb.ca>

paul c wrote:

> Bob Badour wrote:
>

>> paul c wrote:
>>
>>> Bob Badour wrote:
>>>
>>>> paul c wrote:
>>>>
>>>>> J M Davitt wrote:
>>>
>>> ...
>>>
>>>>>> It almost seems as though you want to declare an analogue for DUM,
>>>>>> syntax-check some expressions, and add attributes to your relation
>>>>>> with the confidence that your expressions are still correct.
>>>>>
>>>>>
>>>>> Not exactly how I thought of it, but I think that's fair, after 
>>>>> all, one can add attributes, subject to one's external conception, 
>>>>> to relation definitions that don't have empty headings, in fact not 
>>>>> that the observation is of any use, that seems to be what happens 
>>>>> when one defines a relation with one attribute.
>>>>
>>>> I suggest an empty candidate key in a relation with any number of 
>>>> attributes is closer.
>>>
>>> I don't catch your drift.  If we are on the same page, then trying to 
>>> equate a relation that has either no rows or one row with a relation 
>>> whose name is mis-spelled is indeterminate.  If doing that is the 
>>> same then I would have to give up on my original question.
>>
>> You suggested that adding an attribute to a degree zero relation is a 
>> degree one relation. However, whether one adds one attribute or an 
>> arbitrary number of attributes is less important than the fact that 
>> the candidate key will have an empty set of attributes.
>> ...

>
> Thanks, I will try to ponder that in some way different from how I've
> been looking at it. Strictly speaking, I wasn't aware that one could
> 'add' an attribute to a relation, nor that any 'key' would persevere.

The extend operation creates a new relation by adding an attribute to an existing one. Strictly speaking, whether the candidate key would be preserved depends on the operation used to derive the extended attributes. Ungrouping a relation valued attribute, for instance, would affect the key. However, most familiar extend operations would not.

>> Identifying the error condition is easy. The problem of identification 
>> only arises after you replace the error with DEE or DUM.
>> ...

>
> It seems (as usual) that I haven't explained myself well enough. While
> at the UI, I think most people would consider a spelling error an error,
> I would like, at a very low internal level, to ignore typo's of that
> sort, evaluate it as written, and give a result that is logically
> consistent (assuming that is logically possible). I want to postpone
> what error decisions are shown at the UI level.

Postponing seems counterproductive on a number of levels. From a user's perspective, getting a timely and somewhat detailed error message is much better than someday getting a highly detailed error message that includes details of something the user never asked for or wanted. Received on Thu Jun 29 2006 - 20:24:12 CDT