Re: getXXX methods

There is a table in the jdbc spec which suggests that
there is a preferred method for getting the column information, and at
non-preferred method.

For example

getByte can be used to get a:

byte --- obviously
short
long
real
float
double
decimal
numeric
bit
char
varchar
longvarchar

Currently this is not implemented as such, there are a few questions I
have though

would all the numeric values be truncated ?

What do we do with char, varchar, longvarchar ?

--
Dave Cramer
519 939 0336
ICQ # 14675561
www.postgresintl.com

On Fri, 2 Jul 2004, Dave Cramer wrote:

> There is a table in the jdbc spec which suggests that
> there is a preferred method for getting the column information, and at
> non-preferred method.
>
> would all the numeric values be truncated ?
>
> What do we do with char, varchar, longvarchar ?

It's tough to say. Looking at the current situation for retrieving double
values with getInt() the current driver will throw an Exception on a out
of range value because it starts with a String and uses Integer.parseInt()
on it. Contrast this with the result of

Double d = new Double(Double.MAX_VALUE);
System.out.println(d.intValue());

which truncates the double to Integer.MAX_VALUE. The javadocs are
useless, but I prefer the Exception to silent truncation, so I would
suggest getByte can be used on any integer value of -128 to 127 regardless
of its storage form (like text). The question of comparing floating point
numbers should be the same, but we may run into problems when 1 is
represented as 1.00000001.

Kris Jurka

Once possibility is to use Double.parseDouble(s).byteValue()

so the code would become

try
{
Byte.parseByte(s)
}
catch(NumberFormatException e)
{
try
{
return Double.parseDouble(s).ByteValue();
}
catch( NumberFormatException ne )
{
throw exception;
}
}

Dave
On Tue, 2004-07-06 at 14:46, Kris Jurka wrote:
> On Fri, 2 Jul 2004, Dave Cramer wrote:
>
> > There is a table in the jdbc spec which suggests that
> > there is a preferred method for getting the column information, and at
> > non-preferred method.
> >
> > would all the numeric values be truncated ?
> >
> > What do we do with char, varchar, longvarchar ?
>
> It's tough to say. Looking at the current situation for retrieving double
> values with getInt() the current driver will throw an Exception on a out
> of range value because it starts with a String and uses Integer.parseInt()
> on it. Contrast this with the result of
>
> Double d = new Double(Double.MAX_VALUE);
> System.out.println(d.intValue());
>
> which truncates the double to Integer.MAX_VALUE. The javadocs are
> useless, but I prefer the Exception to silent truncation, so I would
> suggest getByte can be used on any integer value of -128 to 127 regardless
> of its storage form (like text). The question of comparing floating point
> numbers should be the same, but we may run into problems when 1 is
> represented as 1.00000001.
>
> Kris Jurka
>
>
>
> !DSPAM:40eaf9e7148133410918667!
>
>
--
Dave Cramer
519 939 0336
ICQ # 14675561

On Tue, 6 Jul 2004, Dave Cramer wrote:

> Once possibility is to use Double.parseDouble(s).byteValue()
>
> so the code would become
>
> try
> {
> Byte.parseByte(s)
> }

Why bother with Byte.parseByte at all if you are going to fall back to the
double parsing anyway? As I mentioned earlier I think it is better to
throw an Exception rather than to silently alter the returned data.

Kris Jurka

I was thinking that parsing the double would be less efficient than
Byte.parseByte().

The spec suggests that the user would know what they are doing calling
getByte on a double column.

Dave
On Tue, 2004-07-06 at 17:01, Kris Jurka wrote:
> On Tue, 6 Jul 2004, Dave Cramer wrote:
>
> > Once possibility is to use Double.parseDouble(s).byteValue()
> >
> > so the code would become
> >
> > try
> > {
> > Byte.parseByte(s)
> > }
>
> Why bother with Byte.parseByte at all if you are going to fall back to the
> double parsing anyway? As I mentioned earlier I think it is better to
> throw an Exception rather than to silently alter the returned data.
>
> Kris Jurka
>
>
>
> !DSPAM:40eb133321082025652008!
>
>
--
Dave Cramer
519 939 0336
ICQ # 14675561

Dave Cramer wrote:
> I was thinking that parsing the double would be less efficient than
> Byte.parseByte().
>
> The spec suggests that the user would know what they are doing calling
> getByte on a double column.

Yeah, specifically table B-6 says you can use getByte() on pretty much
any numeric SQL type, and (bizarrely) on varchar, char, longvarchar, and
boolean types too.

The spec & javadoc for java.sql.DataTruncation implies we should
generate DataTruncation as a warning if we truncate data on read. I
suppose that loss of precision counts as truncation?

-O

Oliver,

Well as Kris pointed out the javadoc is next to useless here. I see no
harm in truncating the data, my assumption being that the user knows
what they are doing.

Dave
On Tue, 2004-07-06 at 19:40, Oliver Jowett wrote:
> Dave Cramer wrote:
> > I was thinking that parsing the double would be less efficient than
> > Byte.parseByte().
> >
> > The spec suggests that the user would know what they are doing calling
> > getByte on a double column.
>
> Yeah, specifically table B-6 says you can use getByte() on pretty much
> any numeric SQL type, and (bizarrely) on varchar, char, longvarchar, and
> boolean types too.
>
> The spec & javadoc for java.sql.DataTruncation implies we should
> generate DataTruncation as a warning if we truncate data on read. I
> suppose that loss of precision counts as truncation?
>
> -O
>
>
>
> !DSPAM:40eb3871277871679725527!
>
>
--
Dave Cramer
519 939 0336
ICQ # 14675561

Dave Cramer wrote:
> Oliver,
>
> Well as Kris pointed out the javadoc is next to useless here. I see no
> harm in truncating the data, my assumption being that the user knows
> what they are doing.

If the application really wants silent truncation without warning can't
they do it directly in the query?

I think generating DataTruncation (nb: as a *warning*, not throwing an
exception) is still a good idea. Then at least the application gets some
sort of notification.

Have you read the DataTruncation javadoc & spec section?

-O

hmmm... Ok, just read it.

Presumably the warning would be added to the result set object?

I doubt this was the intended use as the table infers that using any of
the non-preferred methods will cast to the requested type. I do see
this as a good thing assuming the programmer is aware of the warnings,
and is handling them.

I do have one concern however: Lets suppose that the user gets a very
large result set and starts scrolling through it, we keep adding
warnings to it and we run out of memory?

Dave
On Tue, 2004-07-06 at 21:10, Oliver Jowett wrote:
> Dave Cramer wrote:
> > Oliver,
> >
> > Well as Kris pointed out the javadoc is next to useless here. I see no
> > harm in truncating the data, my assumption being that the user knows
> > what they are doing.
>
> If the application really wants silent truncation without warning can't
> they do it directly in the query?
>
> I think generating DataTruncation (nb: as a *warning*, not throwing an
> exception) is still a good idea. Then at least the application gets some
> sort of notification.
>
> Have you read the DataTruncation javadoc & spec section?
>
> -O
>
>
>
> !DSPAM:40eb4d8f105802968417614!
>
>
--
Dave Cramer
519 939 0336
ICQ # 14675561

On Wed, 7 Jul 2004, Oliver Jowett wrote:

> If the application really wants silent truncation without warning can't
> they do it directly in the query?
>
> I think generating DataTruncation (nb: as a *warning*, not throwing an
> exception) is still a good idea. Then at least the application gets some
> sort of notification.
>
> Have you read the DataTruncation javadoc & spec section?
>

It makes sense to me on the write side where a database could truncate
data to a varchar(N) column instead of erroring, but pg considers this and
numeric out of range values as errors. On the read side assuming that the
user "knows what they are doing" seems wrong. Consider a likely situation
like a int8 column value being retrieved with getInt(), it works fine for
years, but once hitting the limit on integer size a truncation would
cause bizarre application errors.

Section 8.3.1 of the spec clearly seems to indicate that a silent
truncation is a special case and that shouldn't be our behavior for other
data types than those specifically affected by setMaxFieldSize(). The
DataTruncation API is organized around byte sizes and just doesn't seem
right for numeric data. Even if the spec does imply that a warning
shuold be issued (which is not clear to me), I can't imagine why
anyone would want this. If I want truncation I'll do it myself, otherwise
I want any error to immediately raise a red flag and put the brakes on
processing. How many people really check for warnings anyway?

Kris Jurka

Kris Jurka wrote:

> The
> DataTruncation API is organized around byte sizes and just doesn't seem
> right for numeric data.

There is support throughout that API for "unknown sizes" which seems
appropriate when you're not dealing with explicitly-sized types. And
even types such as varchar don't map directly to bytes anyway..

> Even if the spec does imply that a warning
> shuold be issued (which is not clear to me), I can't imagine why
> anyone would want this. If I want truncation I'll do it myself, otherwise
> I want any error to immediately raise a red flag and put the brakes on
> processing.

I tend to agree -- but Dave evidently has a use for it, in which case
truncation+warning seems a lesser evil than silent truncation.

> How many people really check for warnings anyway?

I hate this argument. If we don't generate any warnings, of course no
one will check for them!

-O

On Wed, 7 Jul 2004, Oliver Jowett wrote:

> > How many people really check for warnings anyway?
>
> I hate this argument. If we don't generate any warnings, of course no
> one will check for them!

No, this is different. Exceptions are supposed to prevent you from
checking the return code on every function call, which the warning API
seems to want to you to do.

Kris Jurka

Ok, it appears (at least from my understanding) that Kris is correct
here.

I had a look at the sql2003 proposed spec (ISO/IEC 9075-2:2003(E)), and
it states:

A number is assignable only to sites of numeric type. If an assignment
of some number would result in a loss of it's most significant digit, an
exception conditions is raised. If least significant digits are lost,
implementation defined rounding, or truncation occurs, with no exception
condition being raised.

Dave

On Tue, 2004-07-06 at 21:58, Kris Jurka wrote:
> On Wed, 7 Jul 2004, Oliver Jowett wrote:
>
> > > How many people really check for warnings anyway?
> >
> > I hate this argument. If we don't generate any warnings, of course no
> > one will check for them!
>
> No, this is different. Exceptions are supposed to prevent you from
> checking the return code on every function call, which the warning API
> seems to want to you to do.
>
> Kris Jurka
>
>
>
> !DSPAM:40eb58bf196361343028809!
>
>
--
Dave Cramer
519 939 0336
ICQ # 14675561

On Wed, 7 Jul 2004, Dave Cramer wrote:

> Ok, it appears (at least from my understanding) that Kris is correct
> here.
>
> I had a look at the sql2003 proposed spec (ISO/IEC 9075-2:2003(E)), and
> it states:

Well the SQL spec and the JDBC spec are different things. I was basing
part of my argument on the SQL spec's logic and extending that to fill in
the holes in the JDBC spec, but I don't consider this definitive. I still
feel this is the right thing to do, but I don't want to close off the
discussion if people feel otherwise.

Kris Jurka

I think that since the SQL spec is referenced at the end of the JDBC
spec that it has some relevance. I just thought that in absence of a
second, or third opinion this would suggest a course of action?

Dave
On Thu, 2004-07-08 at 02:50, Kris Jurka wrote:
> On Wed, 7 Jul 2004, Dave Cramer wrote:
>
> > Ok, it appears (at least from my understanding) that Kris is correct
> > here.
> >
> > I had a look at the sql2003 proposed spec (ISO/IEC 9075-2:2003(E)), and
> > it states:
>
> Well the SQL spec and the JDBC spec are different things. I was basing
> part of my argument on the SQL spec's logic and extending that to fill in
> the holes in the JDBC spec, but I don't consider this definitive. I still
> feel this is the right thing to do, but I don't want to close off the
> discussion if people feel otherwise.
>
> Kris Jurka
>
>
>
> !DSPAM:40eceebb46734039016794!
>
>
--
Dave Cramer
519 939 0336
ICQ # 14675561

Well, I have an interesting problem...

Detecting that a value is greater than MaxLong?

If I parse it using Double.parseDouble, and it is greater than LongMax
by 1 or so, the value ends up actually being less due to rounding ?

Any suggestions?

Dave
On Thu, 2004-07-08 at 08:11, Dave Cramer wrote:
> I think that since the SQL spec is referenced at the end of the JDBC
> spec that it has some relevance. I just thought that in absence of a
> second, or third opinion this would suggest a course of action?
>
> Dave
> On Thu, 2004-07-08 at 02:50, Kris Jurka wrote:
> > On Wed, 7 Jul 2004, Dave Cramer wrote:
> >
> > > Ok, it appears (at least from my understanding) that Kris is correct
> > > here.
> > >
> > > I had a look at the sql2003 proposed spec (ISO/IEC 9075-2:2003(E)), and
> > > it states:
> >
> > Well the SQL spec and the JDBC spec are different things. I was basing
> > part of my argument on the SQL spec's logic and extending that to fill in
> > the holes in the JDBC spec, but I don't consider this definitive. I still
> > feel this is the right thing to do, but I don't want to close off the
> > discussion if people feel otherwise.
> >
> > Kris Jurka
> >
> >
> >
> >
> >
> >
--
Dave Cramer
519 939 0336
ICQ # 14675561

Dave Cramer wrote:
> Well, I have an interesting problem...
>
> Detecting that a value is greater than MaxLong?
>
> If I parse it using Double.parseDouble, and it is greater than LongMax
> by 1 or so, the value ends up actually being less due to rounding ?
>
> Any suggestions?

The problem is that you're going via a double, you're going to lose
precision there regardless of what you do (you don't have 64 bits of
mantissa+sign to play with).

If you want to retain precision, don't use a double as your intermediate
value. Perhaps extract everything before the first '.' and use
parseLong? That will truncate rather than round the value though.

I don't like the whole idea of silently losing data anyway..

-O