Daniel John Debrunner wrote:
...
How much demand for this type, as you've described is there? Are many
Java applications using byte for fields? My guess would have been that
any requests for TINYINT would have been due to existing database
applications.
I think Lance is right: we can see
I thought Rick's suggestion of adding the UNSIGNED keyword was a good
solution -- we can get the best of both worlds...
David
Francois Orsini wrote:
Since Sybase, MySQL and MS SQL Server have had support for UNSIGNED
TINYINT for many years (at least for 2 of them), offering support for an
+1. Original argument of ease of migration from Sybase, Microsoft
servers goes for a toss with a SIGNED implementation. There are too many
issues with the current proposal. I am for making this follow closer to
current implementations, if all.
Satheesh
Francois Orsini wrote:
Since Sybase,
David W. Van Couvering wrote:
I thought Rick's suggestion of adding the UNSIGNED keyword was a good
solution -- we can get the best of both worlds...
So more non-standard syntax? Why is it better for a SQL Server/Sybase
application to change their types to TINYINT UNSIGNED, instead of
Daniel John Debrunner wrote:
David W. Van Couvering wrote:
I thought Rick's suggestion of adding the UNSIGNED keyword was a good
solution -- we can get the best of both worlds...
So more non-standard syntax? Why is it better for a SQL Server/Sybase
application to change their types
Rick Hillegas wrote:
You can also implement NOT NULL as a check contraint. Most databases
consider that to be an inefficiency which it's worth optimizing with
custom logic.
Custom logic that's defined by the SQL Standard. :-)
Dan.
On 11/14/05, Rick Hillegas [EMAIL PROTECTED] wrote:
Daniel John Debrunner wrote:David W. Van Couvering wrote:I thought Rick's suggestion of adding the UNSIGNED keyword was a goodsolution -- we can get the best of both worlds...
So more non-standard syntax? Why is it better for a SQL
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
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
Daniel John Debrunner wrote:
Rick Hillegas wrote:
I logged this enhancment request because it seemed that re-enabling
TINYINT would be low hanging fruit.
I believe how hard or easy an item is has no relevance to if it should
be included in Derby. The criteria should
Since Sybase, MySQL and MS SQL Server have had support for UNSIGNED
TINYINT for many years (at least for 2 of them), offering support for
an UNSIGNED TINYINT rather than SIGNED at this point makes more sense
and can only be good for Derby's adoption (and that a sufficient reason
for adding it
Rick Hillegas wrote:
I see this in section 8.3.4
The JDBC type TINYINT represents an 8-bit integer value between 0 and
255 that may be signed or unsigned.
Hi Dan,
I don't mean to pile up on you after your jet lag. Welcome back!
I wasn't back, it's that three day in jet-lag, but
Yeah, that's the same sentence I saw. It's a bit oddly worded. The
"8-bit integer value" makes it sound like a byte. But "value between 0
and 255 that may be signed or unsigned" could mean a "value between
-256 and 255", that is, a 9-bit quantity. I'm putting my faith in the
As I understand it the value of TINYINT is:
- Enables of migration of applications to Derby
- Allows for better use of storage (which goes in line with our small
footprint goal)
The reason against it is it is a non-standard SQL type. But don't we
already have things in Derby that are not
Lance J. Andersen wrote:
H, that's kind of an awkward place to be in. It seems you want to
add this non-standard SQL type to match other databases, but by matching
the other databases you break the JDBC spec. :-)
I do not see how this is going to break anything. The JDBC spec
indicates
David W. Van Couvering wrote:
As I understand it the value of TINYINT is:
- Enables of migration of applications to Derby
- Allows for better use of storage (which goes in line with our small
footprint goal)
The reason against it is it is a non-standard SQL type. But don't we
already
Daniel John Debrunner wrote:
Lance J. Andersen wrote:
H, that's kind of an awkward place to be in. It seems you want to
add this non-standard SQL type to match other databases, but by matching
the other databases you break the JDBC spec. :-)
I do
Daniel John Debrunner wrote:
David W. Van Couvering wrote:
As I understand it the value of TINYINT is:
- Enables of migration of applications to Derby
- Allows for better use of storage (which goes in line with our "small
footprint" goal)
The reason against it is it is a
Hi Dan,
If I said somewhere that Postgres supports TINYINT, then that was a big,
old lie. Perhaps my brain short-circuited and I meant the other open
source database I care about: MySQL. As you note, MySQL supports a
TINYINT datatype, intended to fit in a byte. I'm looking at a copy of
the
At this point, I think we have agreed on the facts about how JDBC and
various SQL databases treat the TINYINT type. I think I would not be
going out on a limb if I said that there is no industry-wide consensus
about whether TINYINT is a signed or unsigned quantity.
I logged this enhancment
Rick Hillegas wrote:
I logged this enhancment request because it seemed that re-enabling
TINYINT would be low hanging fruit.
I believe how hard or easy an item is has no relevance to if it should
be included in Derby. The criteria should be, is it good for Derby given
Derby's charter.
Satheesh Bandaram wrote:
What does this mean? Section 8.3.4 at
http://java.sun.com/j2se/1.3/docs/guide/jdbc/getstart/mapping.html.
The JDBC TINYINT is intended to represent the datatype on the backend
which in the databases i am familiar with is a range 0-255 such as
Sybase and MS
[
http://issues.apache.org/jira/browse/DERBY-695?page=comments#action_12357163 ]
Daniel John Debrunner commented on DERBY-695:
-
We should be clear that the JDBC spec defines *JDBC Types* and the SQL standard
defines *SQL types*.
Thus they are
Rick Hillegas (JIRA) wrote:
I would like to explore why TINYINT should have to sustain an attack not
mounted against, say, optimizer hints.
I don't think anyone is attacking anything, it's just a discussion of
the various issues and views.
I think optimizer directives went through a similar
http://java.sun.com/j2se/1.3/docs/guide/jdbc/getstart/mapping.html
This mapping is reflected in the data returned by DatabaseMetaData.getTypeInfo
On an implementation note, the link above says TINYINT is valued 0-255 signed
or unsigned, I do not believe that is what was implemented by
Rick Hillegas wrote:
My apologies for the colorful language. I do recall a general discussion
about how there was no standard for optimizer hints. But I don't recall
ANSI's silence on the matter being put forward as an objection.
Well it's kind of scratch your own objection :-)
One
8-bit integer.
I see this in section 8.3.4
"The JDBC type TINYINT represents an 8-bit integer value between 0 and
255 that may be signed or unsigned."
I don't see anything in that section or elsewhere about "fits in a
byte", in fact I see:
"The 8-bit Java byte type
I see this in section 8.3.4
The JDBC type TINYINT represents an 8-bit integer value between 0 and
255 that may be signed or unsigned.
Hi Dan,
I don't mean to pile up on you after your jet lag. Welcome back!
Yeah, that's the same sentence I saw. It's a bit oddly worded. The
8-bit integer
What does this mean? Section 8.3.4 at
http://java.sun.com/j2se/1.3/docs/guide/jdbc/getstart/mapping.html.
"The recommended Java mapping for the JDBC TINYINT
type is as either a Java byte or a Java short.
The 8-bit Java byte type represents a signed value from -128
to 127, so it may not always
29 matches
Mail list logo
