Обсуждение: smallint mapping issue

Hi guys,

Dave tells me this has been discussed recently, but doesn't recall the
thread, so I'll post here.

In postgresql-8.0-311.jdbc3.jar with a column defined as smallint, the
corresponding value returned from getObject() is a Short.

In the current HEAD, that same smallint column is returned as an Integer.

This causes HUGE problems if it's not an oversight, as it makes it
virtually impossible to write JDBC code that works with other dbs
(which typically return Short).

From the JDK 1.5 docs (and all the previous ones as well):
http://java.sun.com/j2se/1.5.0/docs/guide/jdbc/getstart/mapping.html
---------------------------------
8.3.5 SMALLINT

The JDBC type SMALLINT represents a 16-bit signed integer value
between -32768 and 32767.

The corresponding SQL type, SMALLINT, is defined in SQL-92 and is
supported by all the major databases. The SQL-92 standard leaves the
precision of SMALLINT up to the implementation, but in practice, all
the major databases support at least 16 bits.

The recommended Java mapping for the JDBC SMALLINT type is as a Java short.
---------------------------------

Can someone confirm that this is a bug, and if not, a) why (given the
above documentation), and b) how do you expect to deal with the
incompatibility issues this would cause?

Thanks,
Christian

Christian Cryder wrote:

> Dave tells me this has been discussed recently, but doesn't recall the
> thread, so I'll post here.

You might want to search on archives.postgresql.org too.

> In postgresql-8.0-311.jdbc3.jar with a column defined as smallint, the
> corresponding value returned from getObject() is a Short.
>
> In the current HEAD, that same smallint column is returned as an Integer.

Please see table B-3 in the JDBC 3.0 spec:

TABLE B-3 JDBC Types Mapped to Java Object Types
ResultSet.getObject and CallableStatement.getObject use the mapping
shown in this table for standard mappings

[...]

TINYINT Integer
SMALLINT Integer
INTEGER Integer
BIGINT Long

> This causes HUGE problems if it's not an oversight, as it makes it
> virtually impossible to write JDBC code that works with other dbs
> (which typically return Short).

Which other DBs exactly? You should tell them to fix their JDBC drivers :)

It's easy enough to deal with both Short and Integer being returned --
cast to java.lang.Number.

> Can someone confirm that this is a bug, and if not, a) why (given the
> above documentation), and b) how do you expect to deal with the
> incompatibility issues this would cause?

It's not a bug -- it's a deliberate change so that we actually follow
the spec.

Personally I'm not prepared to put much effort into supporting backwards
compatibility with old behaviour that was not spec compliant. Fix your
application.

-O

Hi Oliver,

Yeah, I see what you are talking about in the spec, and we're
certainly not opposed to fixing our app. Here's the difficulty,
however, and this is something I would just encourage everyone to
consider.

We are in the midst of trying to move to Postgres from MS SQL. Our
current app consists of about 7500 lines of code (this doesn't count
our custom OR mapping middleware). We have over 2500 references to
Short's - because that's how NetDirect's MS SQL drivers return
smallints. It's also how MySQL returns them, and I _think_ IBM's DB2
returns them that way as well (I just uninstalled my demo version of
DB2, so I can't easily verify).

So there's several points to consider:

a) in a decent sized app like ours, saying "just change your app" is
not a trivial thing - we can probably fix all those place fairly
easily, but it requires time and testing

b) where it really complicates things is that our current application
is running in production on a db that returns values differently. Now,
it's easy to say "tell them to fix their drivers", but realistically,
that's not an option w/ MS (and I think you guys know this).

c) because we are a pretty-close-to-enterprise app (we handle about
3-5 million trxs a month), there are 2 things that are extremely
important to us: a) performance, b) stability. What that means is that
we can't afford to shoot ourselves in the foot. Which means that
before we can ever consider making a switch to the lovely "we follow
the standards better" postgres, we need to test the crap out of it
while we live with the "we interpret the spec a little differently"
way of other dbs. In other words, we need to be able to have our app
run against both MS (production) and Postgres (test) simultaneously.
So if you insist on doing it your way and your way only, that makes it
a whole lot harder for us.

My point in all this is not that you guys are wrong (I'm actually a
huge fan of sticking to the spec - even though in this case I think
the spec is vague and wrong, I'm still willing to change our code) -
my point is just that by adopting a hardline stance in places of
ambiguity or discrepency we erect barriers to adoption.

We make it hard for people with existing apps - especially if they are
big - to switch to from some other platform to Postgres. I'd rather
see us make it as easy as possible to make the switch to postgres,
especially if we want to see more shops like us (upper midsize dbs)
make the transition.

So my suggestion is "look for ways to support both". In this case, it
would probably be very easy for us to include a configuration param
that tells the driver "return Shorts instead of Integers for type
smallint." This same type of thing could probably help in the
Timestamp issue as well.

I'm very willing to be a guinea pig here - because we have a large
app, we can probably help expose a lot of issues other folks might not
run into. But I'd like to know whether the community is willing to
take a "we can help you find a way to do this" approach, or whether
its just "our way or the highway".

Does that help explain where I'm coming from here?

Christian

On 7/27/05, Oliver Jowett <oliver@opencloud.com> wrote:
> Christian Cryder wrote:
>
> > Dave tells me this has been discussed recently, but doesn't recall the
> > thread, so I'll post here.
>
> You might want to search on archives.postgresql.org too.
>
> > In postgresql-8.0-311.jdbc3.jar with a column defined as smallint, the
> > corresponding value returned from getObject() is a Short.
> >
> > In the current HEAD, that same smallint column is returned as an Integer.
>
> Please see table B-3 in the JDBC 3.0 spec:
>
> TABLE B-3 JDBC Types Mapped to Java Object Types
> ResultSet.getObject and CallableStatement.getObject use the mapping
> shown in this table for standard mappings
>
> [...]
>
> TINYINT Integer
> SMALLINT Integer
> INTEGER Integer
> BIGINT Long
>
> > This causes HUGE problems if it's not an oversight, as it makes it
> > virtually impossible to write JDBC code that works with other dbs
> > (which typically return Short).
>
> Which other DBs exactly? You should tell them to fix their JDBC drivers :)
>
> It's easy enough to deal with both Short and Integer being returned --
> cast to java.lang.Number.
>
> > Can someone confirm that this is a bug, and if not, a) why (given the
> > above documentation), and b) how do you expect to deal with the
> > incompatibility issues this would cause?
>
> It's not a bug -- it's a deliberate change so that we actually follow
> the spec.
>
> Personally I'm not prepared to put much effort into supporting backwards
> compatibility with old behaviour that was not spec compliant. Fix your
> application.
>
> -O
>

In what version of MySQL have you seen the non-standard behavior?

They fixed this when it was pointed out to them, both in their most
popular product:

http://bugs.mysql.com/bug.php?id=1913

and in MaxDb (a rebranded SAP-DB):

http://bugs.mysql.com/bug.php?id=7647


>>> Christian Cryder <c.s.cryder@gmail.com> 07/28/05 11:05 AM >>>
Hi Oliver,

Yeah, I see what you are talking about in the spec, and we're
certainly not opposed to fixing our app. Here's the difficulty,
however, and this is something I would just encourage everyone to
consider.

We are in the midst of trying to move to Postgres from MS SQL. Our
current app consists of about 7500 lines of code (this doesn't count
our custom OR mapping middleware). We have over 2500 references to
Short's - because that's how NetDirect's MS SQL drivers return
smallints. It's also how MySQL returns them, and I _think_ IBM's DB2
returns them that way as well (I just uninstalled my demo version of
DB2, so I can't easily verify).

So there's several points to consider:

a) in a decent sized app like ours, saying "just change your app" is
not a trivial thing - we can probably fix all those place fairly
easily, but it requires time and testing

b) where it really complicates things is that our current application
is running in production on a db that returns values differently. Now,
it's easy to say "tell them to fix their drivers", but realistically,
that's not an option w/ MS (and I think you guys know this).

c) because we are a pretty-close-to-enterprise app (we handle about
3-5 million trxs a month), there are 2 things that are extremely
important to us: a) performance, b) stability. What that means is that
we can't afford to shoot ourselves in the foot. Which means that
before we can ever consider making a switch to the lovely "we follow
the standards better" postgres, we need to test the crap out of it
while we live with the "we interpret the spec a little differently"
way of other dbs. In other words, we need to be able to have our app
run against both MS (production) and Postgres (test) simultaneously.
So if you insist on doing it your way and your way only, that makes it
a whole lot harder for us.

My point in all this is not that you guys are wrong (I'm actually a
huge fan of sticking to the spec - even though in this case I think
the spec is vague and wrong, I'm still willing to change our code) -
my point is just that by adopting a hardline stance in places of
ambiguity or discrepency we erect barriers to adoption.

We make it hard for people with existing apps - especially if they are
big - to switch to from some other platform to Postgres. I'd rather
see us make it as easy as possible to make the switch to postgres,
especially if we want to see more shops like us (upper midsize dbs)
make the transition.

So my suggestion is "look for ways to support both". In this case, it
would probably be very easy for us to include a configuration param
that tells the driver "return Shorts instead of Integers for type
smallint." This same type of thing could probably help in the
Timestamp issue as well.

I'm very willing to be a guinea pig here - because we have a large
app, we can probably help expose a lot of issues other folks might not
run into. But I'd like to know whether the community is willing to
take a "we can help you find a way to do this" approach, or whether
its just "our way or the highway".

Does that help explain where I'm coming from here?

Christian

On 7/27/05, Oliver Jowett <oliver@opencloud.com> wrote:
> Christian Cryder wrote:
>
> > Dave tells me this has been discussed recently, but doesn't recall
the
> > thread, so I'll post here.
>
> You might want to search on archives.postgresql.org too.
>
> > In postgresql-8.0-311.jdbc3.jar with a column defined as smallint,
the
> > corresponding value returned from getObject() is a Short.
> >
> > In the current HEAD, that same smallint column is returned as an
Integer.
>
> Please see table B-3 in the JDBC 3.0 spec:
>
> TABLE B-3 JDBC Types Mapped to Java Object Types
> ResultSet.getObject and CallableStatement.getObject use the mapping
> shown in this table for standard mappings
>
> [...]
>
> TINYINT Integer
> SMALLINT Integer
> INTEGER Integer
> BIGINT Long
>
> > This causes HUGE problems if it's not an oversight, as it makes it
> > virtually impossible to write JDBC code that works with other dbs
> > (which typically return Short).
>
> Which other DBs exactly? You should tell them to fix their JDBC
drivers :)
>
> It's easy enough to deal with both Short and Integer being returned --
> cast to java.lang.Number.
>
> > Can someone confirm that this is a bug, and if not, a) why (given
the
> > above documentation), and b) how do you expect to deal with the
> > incompatibility issues this would cause?
>
> It's not a bug -- it's a deliberate change so that we actually follow
> the spec.
>
> Personally I'm not prepared to put much effort into supporting
backwards
> compatibility with old behaviour that was not spec compliant. Fix your
> application.
>
> -O
>

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Christian Cryder a écrit :
> We are in the midst of trying to move to Postgres from MS SQL. Our
> current app consists of about 7500 lines of code (this doesn't count
> our custom OR mapping middleware). We have over 2500 references to
> Short's - because that's how NetDirect's MS SQL drivers return
> smallints. It's also how MySQL returns them, and I _think_ IBM's DB2
> returns them that way as well (I just uninstalled my demo version of
> DB2, so I can't easily verify).
> [...]
> b) where it really complicates things is that our current application
> is running in production on a db that returns values differently. Now,
> it's easy to say "tell them to fix their drivers", but realistically,
> that's not an option w/ MS (and I think you guys know this).

Did you try the jTDS driver for Sql server (
http://jtds.sourceforge.net/ ) ?

Christian,

One thing you can do to mitigate the impact on your application is to
write a method like this:

public Object getObject(ResultSet rs, int index) {
  Object o = rs.getObject(index);
  if(rs.getMetaData().getColumnType(index) == Types.SMALLINT) {
    if(o instanceof Integer) {
      o = new Short((short)((Integer)o).intValue());
    }
  }
  return o;
}

Unless I'm reading the driver source wrong, calling rs.getMetaData
().getColumnType() is a fast operation and does not require a round-trip
to the database, so there shouldn't be a performance impact.

You could even hide this behavior inside a dynamic proxy class that
reimplements the ResultSet.getObject() method, to avoid making changes
to any of your SQL code.

-- Mark Lewis

On Thu, 2005-07-28 at 10:05 -0600, Christian Cryder wrote:
> Hi Oliver,
>
> Yeah, I see what you are talking about in the spec, and we're
> certainly not opposed to fixing our app. Here's the difficulty,
> however, and this is something I would just encourage everyone to
> consider.
>
> We are in the midst of trying to move to Postgres from MS SQL. Our
> current app consists of about 7500 lines of code (this doesn't count
> our custom OR mapping middleware). We have over 2500 references to
> Short's - because that's how NetDirect's MS SQL drivers return
> smallints. It's also how MySQL returns them, and I _think_ IBM's DB2
> returns them that way as well (I just uninstalled my demo version of
> DB2, so I can't easily verify).
>
> So there's several points to consider:
>
> a) in a decent sized app like ours, saying "just change your app" is
> not a trivial thing - we can probably fix all those place fairly
> easily, but it requires time and testing
>
> b) where it really complicates things is that our current application
> is running in production on a db that returns values differently. Now,
> it's easy to say "tell them to fix their drivers", but realistically,
> that's not an option w/ MS (and I think you guys know this).
>
> c) because we are a pretty-close-to-enterprise app (we handle about
> 3-5 million trxs a month), there are 2 things that are extremely
> important to us: a) performance, b) stability. What that means is that
> we can't afford to shoot ourselves in the foot. Which means that
> before we can ever consider making a switch to the lovely "we follow
> the standards better" postgres, we need to test the crap out of it
> while we live with the "we interpret the spec a little differently"
> way of other dbs. In other words, we need to be able to have our app
> run against both MS (production) and Postgres (test) simultaneously.
> So if you insist on doing it your way and your way only, that makes it
> a whole lot harder for us.
>
> My point in all this is not that you guys are wrong (I'm actually a
> huge fan of sticking to the spec - even though in this case I think
> the spec is vague and wrong, I'm still willing to change our code) -
> my point is just that by adopting a hardline stance in places of
> ambiguity or discrepency we erect barriers to adoption.
>
> We make it hard for people with existing apps - especially if they are
> big - to switch to from some other platform to Postgres. I'd rather
> see us make it as easy as possible to make the switch to postgres,
> especially if we want to see more shops like us (upper midsize dbs)
> make the transition.
>
> So my suggestion is "look for ways to support both". In this case, it
> would probably be very easy for us to include a configuration param
> that tells the driver "return Shorts instead of Integers for type
> smallint." This same type of thing could probably help in the
> Timestamp issue as well.
>
> I'm very willing to be a guinea pig here - because we have a large
> app, we can probably help expose a lot of issues other folks might not
> run into. But I'd like to know whether the community is willing to
> take a "we can help you find a way to do this" approach, or whether
> its just "our way or the highway".
>
> Does that help explain where I'm coming from here?
>
> Christian
>
> On 7/27/05, Oliver Jowett <oliver@opencloud.com> wrote:
> > Christian Cryder wrote:
> >
> > > Dave tells me this has been discussed recently, but doesn't recall the
> > > thread, so I'll post here.
> >
> > You might want to search on archives.postgresql.org too.
> >
> > > In postgresql-8.0-311.jdbc3.jar with a column defined as smallint, the
> > > corresponding value returned from getObject() is a Short.
> > >
> > > In the current HEAD, that same smallint column is returned as an Integer.
> >
> > Please see table B-3 in the JDBC 3.0 spec:
> >
> > TABLE B-3 JDBC Types Mapped to Java Object Types
> > ResultSet.getObject and CallableStatement.getObject use the mapping
> > shown in this table for standard mappings
> >
> > [...]
> >
> > TINYINT Integer
> > SMALLINT Integer
> > INTEGER Integer
> > BIGINT Long
> >
> > > This causes HUGE problems if it's not an oversight, as it makes it
> > > virtually impossible to write JDBC code that works with other dbs
> > > (which typically return Short).
> >
> > Which other DBs exactly? You should tell them to fix their JDBC drivers :)
> >
> > It's easy enough to deal with both Short and Integer being returned --
> > cast to java.lang.Number.
> >
> > > Can someone confirm that this is a bug, and if not, a) why (given the
> > > above documentation), and b) how do you expect to deal with the
> > > incompatibility issues this would cause?
> >
> > It's not a bug -- it's a deliberate change so that we actually follow
> > the spec.
> >
> > Personally I'm not prepared to put much effort into supporting backwards
> > compatibility with old behaviour that was not spec compliant. Fix your
> > application.
> >
> > -O
> >
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster

His challenge is that he has to do that in quite a few places in his
code.

Arguably it should be hidden in a data access object, but his design
is not our concern here

I think given that we are changing the behaviour from one version to
another we may wish to consider
providing a compatibility option.

There are a few places I'd like to see this.

1) this one smallint returned as Short
2) handling setString(type other than string) which used to work


Dave
On 28-Jul-05, at 1:11 PM, Mark Lewis wrote:

> Christian,
>
> One thing you can do to mitigate the impact on your application is to
> write a method like this:
>
> public Object getObject(ResultSet rs, int index) {
>   Object o = rs.getObject(index);
>   if(rs.getMetaData().getColumnType(index) == Types.SMALLINT) {
>     if(o instanceof Integer) {
>       o = new Short((short)((Integer)o).intValue());
>     }
>   }
>   return o;
> }
>
> Unless I'm reading the driver source wrong, calling rs.getMetaData
> ().getColumnType() is a fast operation and does not require a round-
> trip
> to the database, so there shouldn't be a performance impact.
>
> You could even hide this behavior inside a dynamic proxy class that
> reimplements the ResultSet.getObject() method, to avoid making changes
> to any of your SQL code.
>
> -- Mark Lewis
>
> On Thu, 2005-07-28 at 10:05 -0600, Christian Cryder wrote:
>
>> Hi Oliver,
>>
>> Yeah, I see what you are talking about in the spec, and we're
>> certainly not opposed to fixing our app. Here's the difficulty,
>> however, and this is something I would just encourage everyone to
>> consider.
>>
>> We are in the midst of trying to move to Postgres from MS SQL. Our
>> current app consists of about 7500 lines of code (this doesn't count
>> our custom OR mapping middleware). We have over 2500 references to
>> Short's - because that's how NetDirect's MS SQL drivers return
>> smallints. It's also how MySQL returns them, and I _think_ IBM's DB2
>> returns them that way as well (I just uninstalled my demo version of
>> DB2, so I can't easily verify).
>>
>> So there's several points to consider:
>>
>> a) in a decent sized app like ours, saying "just change your app" is
>> not a trivial thing - we can probably fix all those place fairly
>> easily, but it requires time and testing
>>
>> b) where it really complicates things is that our current application
>> is running in production on a db that returns values differently.
>> Now,
>> it's easy to say "tell them to fix their drivers", but realistically,
>> that's not an option w/ MS (and I think you guys know this).
>>
>> c) because we are a pretty-close-to-enterprise app (we handle about
>> 3-5 million trxs a month), there are 2 things that are extremely
>> important to us: a) performance, b) stability. What that means is
>> that
>> we can't afford to shoot ourselves in the foot. Which means that
>> before we can ever consider making a switch to the lovely "we follow
>> the standards better" postgres, we need to test the crap out of it
>> while we live with the "we interpret the spec a little differently"
>> way of other dbs. In other words, we need to be able to have our app
>> run against both MS (production) and Postgres (test) simultaneously.
>> So if you insist on doing it your way and your way only, that
>> makes it
>> a whole lot harder for us.
>>
>> My point in all this is not that you guys are wrong (I'm actually a
>> huge fan of sticking to the spec - even though in this case I think
>> the spec is vague and wrong, I'm still willing to change our code) -
>> my point is just that by adopting a hardline stance in places of
>> ambiguity or discrepency we erect barriers to adoption.
>>
>> We make it hard for people with existing apps - especially if they
>> are
>> big - to switch to from some other platform to Postgres. I'd rather
>> see us make it as easy as possible to make the switch to postgres,
>> especially if we want to see more shops like us (upper midsize dbs)
>> make the transition.
>>
>> So my suggestion is "look for ways to support both". In this case, it
>> would probably be very easy for us to include a configuration param
>> that tells the driver "return Shorts instead of Integers for type
>> smallint." This same type of thing could probably help in the
>> Timestamp issue as well.
>>
>> I'm very willing to be a guinea pig here - because we have a large
>> app, we can probably help expose a lot of issues other folks might
>> not
>> run into. But I'd like to know whether the community is willing to
>> take a "we can help you find a way to do this" approach, or whether
>> its just "our way or the highway".
>>
>> Does that help explain where I'm coming from here?
>>
>> Christian
>>
>> On 7/27/05, Oliver Jowett <oliver@opencloud.com> wrote:
>>
>>> Christian Cryder wrote:
>>>
>>>
>>>> Dave tells me this has been discussed recently, but doesn't
>>>> recall the
>>>> thread, so I'll post here.
>>>>
>>>
>>> You might want to search on archives.postgresql.org too.
>>>
>>>
>>>> In postgresql-8.0-311.jdbc3.jar with a column defined as
>>>> smallint, the
>>>> corresponding value returned from getObject() is a Short.
>>>>
>>>> In the current HEAD, that same smallint column is returned as an
>>>> Integer.
>>>>
>>>
>>> Please see table B-3 in the JDBC 3.0 spec:
>>>
>>> TABLE B-3 JDBC Types Mapped to Java Object Types
>>> ResultSet.getObject and CallableStatement.getObject use the mapping
>>> shown in this table for standard mappings
>>>
>>> [...]
>>>
>>> TINYINT Integer
>>> SMALLINT Integer
>>> INTEGER Integer
>>> BIGINT Long
>>>
>>>
>>>> This causes HUGE problems if it's not an oversight, as it makes it
>>>> virtually impossible to write JDBC code that works with other dbs
>>>> (which typically return Short).
>>>>
>>>
>>> Which other DBs exactly? You should tell them to fix their JDBC
>>> drivers :)
>>>
>>> It's easy enough to deal with both Short and Integer being
>>> returned --
>>> cast to java.lang.Number.
>>>
>>>
>>>> Can someone confirm that this is a bug, and if not, a) why
>>>> (given the
>>>> above documentation), and b) how do you expect to deal with the
>>>> incompatibility issues this would cause?
>>>>
>>>
>>> It's not a bug -- it's a deliberate change so that we actually
>>> follow
>>> the spec.
>>>
>>> Personally I'm not prepared to put much effort into supporting
>>> backwards
>>> compatibility with old behaviour that was not spec compliant. Fix
>>> your
>>> application.
>>>
>>> -O
>>>
>>>
>>
>> ---------------------------(end of
>> broadcast)---------------------------
>> TIP 2: Don't 'kill -9' the postmaster
>>
>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
>        subscribe-nomail command to majordomo@postgresql.org so that
> your
>        message can get through to the mailing list cleanly
>
>

Christian Cryder wrote:

[...]

> Does that help explain where I'm coming from here?

Sure, I understand exactly where you're coming from.

If you want a stable, unchanging, tested-for-your-application driver, I
suggest you import from whatever spot in CVS serves your needs and
maintain it yourself. You can selectively backpatch bugfixes from the
official driver as needed. (this is exactly what Open Cloud does for our
product, BTW, it's just that because I also hack on the official driver
the changes aren't usually all that big -- any fixes we need I try to
push back into the official driver)

I don't really want to see the official driver become even more of a
maze of twisty little backwards-compatibility hacks than it already is..

> whether its just "our way or the highway".

I don't mean it to come across like that. The problem is that it's
likely that any particular change in the driver is going to affect
someone out there adversely.. trying to carefully work around this in
every case seems like a recipe for paralysis. We have perhaps 1/4 of a
developer working on the driver between myself, Kris, and Dave, so we
really don't have tons of development time spare :/   And when a
complete CVS history is there for the taking.. it's not like we're
forcing you to use a particular version.

If you think there's something the driver should be doing that it
doesn't (say, a URL option to control this Short vs Integer behaviour),
the fastest way to get it done is to submit a good patch..

-O

Dave Cramer wrote:

> 1) this one smallint returned as Short
> 2) handling setString(type other than string) which used to work

Maybe we should just toss these both into the "compatible=7.4" bucket
and not try to support them beyond that, since they are both arguably
application errors?

-O

On 28-Jul-05, at 8:26 PM, Oliver Jowett wrote:

> Dave Cramer wrote:
>
>
>> 1) this one smallint returned as Short
>> 2) handling setString(type other than string) which used to work
>>
>
> Maybe we should just toss these both into the "compatible=7.4" bucket
> and not try to support them beyond that, since they are both arguably
> application errors?

When I wrote the original email, I realized that we can't support too
many of these as the
complexity will soon be un-manageable. I'd prefer to see the
setString be the default behaviour, but at this point it's an
indefensible position. Do we have documentation as to what is or
isn't "compatible=7.4" ?

--dc--
>
> -O
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
>        choose an index scan if your joining column's datatypes do not
>        match
>
>

Dave Cramer
davec@postgresintl.com
www.postgresintl.com
ICQ #14675561
jabber davecramer@jabber.org
ph (519 939 0336 )

Dave Cramer wrote:
> Do we have documentation as to what is or  isn't
> "compatible=7.4" ?

I don't think there's currently anything that's 7.4-specific.

-O

On Fri, Jul 29, 2005 at 12:23:43PM +1200, Oliver Jowett wrote:
> Christian Cryder wrote:
>
> [...]
>
> > Does that help explain where I'm coming from here?
>
> Sure, I understand exactly where you're coming from.
>
> If you want a stable, unchanging, tested-for-your-application driver, I
> suggest you import from whatever spot in CVS serves your needs and
> maintain it yourself. You can selectively backpatch bugfixes from the
> official driver as needed. (this is exactly what Open Cloud does for our
> product, BTW, it's just that because I also hack on the official driver
> the changes aren't usually all that big -- any fixes we need I try to
> push back into the official driver)

> I don't really want to see the official driver become even more of a
> maze of twisty little backwards-compatibility hacks than it already is..


> We have perhaps 1/4 of a
> developer working on the driver between myself, Kris, and Dave, so we
> really don't have tons of development time spare :/   And when a
> complete CVS history is there for the taking.. it's not like we're
> forcing you to use a particular version.


Christian,

You can find the cause of your despair here:


http://gborg.postgresql.org/cgi-bin/cvsweb.cgi/pgjdbc/org/postgresql/jdbc2/AbstractJdbc2ResultSet.java.diff?r1=1.74;r2=1.75;cvsroot=pgjdbc

As you can see there, the "bug/feature" you are asking for seems to be
just the matter of the following line of code:

  case Types.SMALLINT:
            return new Short(getShort(columnIndex));


You really don't need any seasoned developer to check out a stable
release from CVS (using a tag), rolling back this change above and
compiling a driver customized to your needs. You don't even need to
know Java. Considering what you said about your business, it would be
surprising that you don't have anyone in-house skilled enough for
that. The time your team will spent on this issue, or the fees you
gonna pay to the OpenCloud-like company which will deal with it for
you, will both surely be pale compared to the licensing costs you were
paying before Postgres :-)

Cheers,

Marc.