Re: No exceptions?
Date: Fri, 30 Jun 2006 01:24:12 GMT
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 Fri Jun 30 2006 - 03:24:12 CEST