Re^4: Typeless Relational Database

[etcshadow]

in reply to Re^3: Typeless Relational Database
in thread Typeless Relational Database

So it's your contention that "DAYOFMONTH(...)" is not a type-conversion? I see one type going in (date) and a different type coming out (number). Or do you mean to say that only type-conversions that are built-in functions (but excluding the to_X(...) ones) are ok to use? Seems like an arbitrary line. Also, I doubt whether the makers of RDBMS have figured out every possible built-in type-converting function that might make sense to exist (good RDMSs allow developers to define their own functions for a reason).

As for the second, yes, I know full well that it's an optimization. An ugly one, in fact. The sort of thing that I don't even write out by hand, but have perl code generate for me. However, I don't think that makes it "wrong". Premature optimization is wrong, sure, but necessary optimization is... well... necessary. And it is hardly "wrong".

I think I'm sounding upset, and that's not how I mean it. I'm not upset at all, nor am I trying to turn this into a heated argument. I was just being pedantic about the absolutism of your statement that type-conversion is ALWAYS wrong. I heartily agree that type-conversion is *usually* wrong. But it's a lot less always wrong than goto, for example, and even goto has, like, one or two legitimate uses.

[dragonchild]

I don't think of DAYOFMONTH() as a type-conversion. I think of it as a one-way data transformation. I'm extracting data, not converting the type. This may sound like semantics, but it's not. For example, do you consider accessors as type converters? You can think of DAYOFMONTH as an accessor on a DATE column. Now, if you were to write a DAYOFMONTH function in Oracle, that wouldn't be a type converter. It may utilize type-conversion as part of its process, but that's irrelevant to the user.

Optimizations aren't wrong, and they don't violate the hard rule I mentioned. Well, they do, but they do so because they're increasing developer cost to reduce some other cost that's been deemed more important. The hard rule I mentioned assumes you want to minimize developer cost. If you don't, then violate the rule. :-)

Goto has plenty of uses. Unfettered goto is less useful. Remember - next and last are both goto statements with severe restrictions. The only hard and fast rule I can think of is that every rule has an exception, usually because you sidestepped one of its assumptions.