db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Francois Orsini <francois.ors...@gmail.com>
Subject Re: [jira] Commented: (DERBY-695) Re-enable the TINYINT datatype
Date Tue, 15 Nov 2005 00:53:34 GMT
This is highly arguable - you say SQL is ugly as it is (which is arguable by
itself ;)) but then you think it's ok to add a non-standard UNSIGNED keyword
if we want the unsigned version which has been there for more than 15 years
at least in very well known RDBMS out there ;)

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


If we end-up supporting both semantics,

On 11/14/05, Dag H. Wanvik <Dag.Wanvik@sun.com> wrote:
> Hi,
> >>>>> "Francois" == Francois Orsini <francois.orsini@gmail.com>
> 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

View raw message