Skip site navigation (1) Skip section navigation (2)

Re: Re: Large Object problems (was Re: JDBC int8 hack)

From: Kyle VanderBeek <kylev(at)yaga(dot)com>
To: lockhart(at)fourpalms(dot)org
Cc: Peter Mount <peter(at)retep(dot)org(dot)uk>, pgsql-patches(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Re: Large Object problems (was Re: JDBC int8 hack)
Date: 2001-04-11 20:46:44
Message-ID: 20010411134644.Y30314@yaga.com (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
On Wed, Apr 11, 2001 at 02:57:16AM +0000, Thomas Lockhart wrote:
> > Alright man, you've got me confused.  Are you saying that despite the
> > existance of INT8 as a column type, and PreparedStatement.setLong(), that
> > these ought not be used?  If so, there is a really big warning missing
> > from the documentation!
> 
> Ah, it just dawned on me what might be happening: Peter, I'm guessing
> that you are thinking of "INT48" or some such, the pseudo-integer array
> type. Kyle is referring to the "int8" 8 byte integer type.

Yes!

> > I guess I'm asking this: I've got an enterprise database runnign 7.0.3
> > ready to go using INT8 primary keys and being accessed through my
> > re-touched JDBC driver.  Am I screwed?  Is it going to break?  If so, I
> > need to fix this all very, very fast.
> 
> btw, it might be better to use a syntax like
> 
>   ... where col = '1234';
> 
> or
> 
>  ... where col = int8 '1234';
> 
> If the former works, then that is a bit more generic that slapping a
> "::int8" onto the constant field.

It seems like a wash to me; either way gets the desired result.  Tacking 
on ::int8 was the quickest.  It also seems neater than this:

   set(parameterIndex, ("int8 '" + new Long(x)).toString() + "'");

in PreparedStatement.setLong().

> I'd imagine that this could also be coded into the app; if so that may
> be where it belongs since then the driver does not have to massage the
> queries as much and it will be easier for the *driver* to stay
> compatible with applications.

This seems to be the wrong idea to me.  The idea is that JDBC allows you 
to be a little bit "backend agnostic".  It'd be pretty disappointing if 
this wasn't true for even the base types.  Application programmers should 
just call setLong() they're dealing with an 8-byte (Long or long) integer.  
It'd be a shame to have a PostgreSQL-specific call to setString("int8 '" + 
x.toString() + "'") littering your code.  That seems to fly in the face of 
everything that JDBC/DBI/ODBC (etc) are about.

-- 
Kyle.
   "I hate every ape I see, from chimpan-A to chimpan-Z" -- Troy McClure

In response to

pgsql-hackers by date

Next:From: Oliver ElphickDate: 2001-04-11 20:55:46
Subject: Re: RPM upgrade caveats going from a beta version to RC
Previous:From: Lamar OwenDate: 2001-04-11 20:30:02
Subject: Re: RPM upgrade caveats going from a beta version to RC

pgsql-patches by date

Next:From: Patrick WelcheDate: 2001-04-12 16:15:52
Subject: Re: Call for platforms
Previous:From: Thomas LockhartDate: 2001-04-11 02:57:16
Subject: Re: Large Object problems (was Re: JDBC int8 hack)

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group