Hi Rene,

I am wondering if the driver I am using is outdated (the functionality I am
looking for seems to be already implemented, since Aug 24).

In fact, I see what you saw about the cache, and looking into it a bit deeper,
the cache is effectively updated (at least, on CVS HEAD).

Could anyone tell me the date of the driver jars present on
http://jdbc.fastcrypt.com ?

If it's older than Aug 24, maybe the solution consists simply on creating the
new jar files.

Thank you very much.


BTW: Brian Weller told me that:

> The cvs server recently changed, use this instead:
> cvs -d :pserver:[EMAIL PROTECTED]:/projects/cvsroot login
> password: postgresql
> cvs -d :pserver:[EMAIL PROTECTED]:/projects/cvsroot co pgsql

End of Brian Weller e-mail.

Thank you very much, Brian.

I (Antonio Fiol Bonnín) wrote some time ago:

> Rene Pijlman wrote:
> > On Fri, 21 Sep 2001 17:26:20 +0200, you wrote:
> > >When looking at the traffic that is going in and out of my machine, I
> > >see many (a real lot of) times the same request. Something like:
> > >
> > >select typname from pg_type where oid = XXX
> > >
> > >where XXX is a number (23, 1184, or maybe others)
> > >
> > >As I use the getObject method to retrieve the different ocjects
> > >contained in the resultset (I can't tell whether it's going to be an
> > >number or a timestamp beforehand), I imagine that this select statement
> > >is the one that helps getObject choose the right type. But, as every row
> > >in the resultset will have the same column types, couldn't some caching
> > >accelerate everything a lot?
> >
> > Looking at the source, I see signs of a caching mechanism in
> > org.postgresql.Connection.getSQLType(), but at first glance it
> > seems that this method doesn't actually add the type it
> > retrieves to its own cache. That could very well be the cause of
> > the problem.
> That will help, probably.
> > Do you intend to fix this yourself, or are you seeking help from
> > this list? If so, it would be nice if you could post a small
> > program that reproduces the problem. Its probably very simple,
> > but that way we can be sure we're looking at the same problem.
> I was going to try it myself. However, I have not been able to get the
> current sources from CVS, as stated below. (I have just retried)
> > >I have tried to connect to CVS, but instructions on
> > >http://www.ca.postgresql.org/devel-corner/docs/postgres/cvs.html
> > >did not work for me. I got:
> > >cvs login: authorization failed: server postgresql.org rejected access
> > >to /home/projects/pgsql/cvsroot for user anoncvs
> >
> > The CVS system is being migrated and there are lots of posts
> > about it on the pgsql-hackers list. I'm not sure what the latest
> > status is. The latest information should be on
> > http://developer.postgresql.org/, but because of the recent
> > shutdown of Great Bridge the system is in flux.
> I used the information present on that site.
> If you can have a look at it, what I do is a
> select a::integer, b::timestamp, c::float from table;
> and then I populate vectors by stating
> myVectorA.add(rs.getObject("a"));
> and the same for b and c.
> table has quite a few rows (about 100 to 700, average 250).
> When the code executes, if I start a network packet capture (after many
> packets have already passed), I see the stated request about the types (and
> presumably its response) going up and down.
> I am using the precompiled driver for Java 1.2 found on
> http://jdbc.fastcrypt.com.
> Thank you very much if you may help, either by letting me access the current
> source or by providing repaired binaries ;-)
> Now seriously, I am willing to repair this, if possible.
> Thanks.
> Antonio
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster

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

Reply via email to