Either way is fine really (as long both semantics end-up being supported at the end)...It's a question of views and priorities from different people having different niches ;)
--francois
If we end-up supporting both semantics,
On 11/14/05, Dag H. Wanvik <[EMAIL PROTECTED]> wrote:
Hi,
>>>>> "Francois" == Francois Orsini <[EMAIL PROTECTED]> wrote:
Francois> Dan's argument which is mine too I believe is in respect with users
Francois> migrating from Sybase/MS SQL Server apps using TINYINT to Derby - if we
Francois> provide an unsigned type by default then they don't have anything to change
Francois> in respect with that type (same semantics) - MySQL has support for both
Francois> SIGNED and UNSIGNED so what not have (unsigned) TINYINT supported in Derby
Francois> by default and encompass a wider range of databases supporting (unsigned)
Francois> TINYINT which in the end will ease migration and help Derby's adoption...
So it would seem this boils down to which consideration is more
important; semantic consistency (=>TINYINT is by default signed, since
other integer types are signed in Derby), or ease of portability to
Derby (=> TINYINT is unsigned by default, since 2 major players use
that).
I would argue that a single byte data type is useful in its own right,
and will favor signed semantics as the default - to keep things clean,
SQL is ugly enough as it is.. If we want the unsigned version
also, I would vote for the UNSIGNED keyword, the type is non-standard
syntax in SQL anyway.
Disclaimer: I guess I should add I am a little biased against unsigned
integer types in general, I have seen far too many bugs due to
indiscriminate mixing of signed and unsigned types over the years ;-)
Thanks,
Dag
