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
