Subject RE: [ib-support] Re: Boolean Fields
Author Paul Schmidt
On 28 Dec 2001, at 14:07, Martijn Tonies wrote:

> 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 :)

It is and it isn't, NULL represents an unknown value, which means
we need it, however there is another way to represent a NULL
value, for other field types, so maybe we don't need a flag on the
datatype, so we can get 8 booleans per byte.

> >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.

And comes with a fresh new set of problems, such as bugs, and
the fact that it makes the engine that much larger.

> >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.

Perhaps the discussion should be, what can we use to add a lot of
power to the engine at a low cost. Maybe the ability to allow the a
UDF to manage a datatype, is something that could be done fairly
inexpensively, so those folks who absolutely need MS-SQL
compatability can simply write a UDF to emulate all of the
extranious datatypes. Maybe this kind of mechanism is the way to
fix most of the irritating things some people find with the engine,
move those functions out to the UDF library, so if someone wants a
different security mechanism, they simply have to write a UDF to
manage it. However this has moved beyond the scope of a UDF
more into a DB level shared library. This kind of extension
mechanism, means you could get to a 75K executable, that loads
a collection of libraries to give you a working engine.


Paul Schmidt
Tricat Technologies