Hi,

>> Beyond that boolean datatypes worry me semantically - not the domains,
>> which people seem to be able to live with, but real boolean types.
>> Assuming that c1 is a boolean column, I would expect to be able to do
>> this:
>>
>> where t1.c1 or t1.c2 = 12
>> or
>> set t1.c1 = NOT t1.c1
>>
>> That's going to require applying force and violence to Claudio's
>> well beloved parser.
>>
>
>A true boolean would allow three values, TRUE, FALSE and NULL,
>so a boolean would really be a two bit value, one bit representing
>the NULL flag, and the second bit representing the true/false value.

NULL is not a value :)

>Do we really need it, probably not, here is a semi-related question

There's a difference between _really_ needing something (as in:
at this very moment) and needing it. Perhaps you and I don't
need it, but other engines are supporting a wide range of data-
types. Take, for example, a native GUID, Boolean, Bit etc in
account and it all stacks up. Every new datatype is a new feature.

>though, how powerful is the UDF mechanism? Perhaps it could be
>expanded, so that a UDF could be used to manage a data-type,
>then folks could add their own data types. We could then work
>towards an engine that simply calls UDFs to do all of it's work.

This would give you a lot more power compared to Domains for sure.

Martijn Tonies
InterBase Workbench - the developer tool for InterBase and Firebird
http://www.interbaseworkbench.com


[Non-text portions of this message have been removed]