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

Re: Bug with caching SQLTypes in Connection:getSQLType(oid)

From: "Dave Cramer" <Dave(at)micro-automation(dot)net>
To: "'Ned Wolpert'" <wolpert(at)yahoo(dot)com>, <pgsql-jdbc(at)postgresql(dot)org>
Cc: "'Barry Lind'" <barry(at)xythos(dot)com>
Subject: Re: Bug with caching SQLTypes in Connection:getSQLType(oid)
Date: 2001-12-10 19:43:03
Message-ID: 006101c181b2$e2022e00$c201a8c0@inspiron (view raw, whole thread or download thread mbox)
Lists: pgsql-jdbc
If we are going to try to get this in as a bug fix for 7.2RC1 then I
would like to see something more conclusive.

Can we verify that the patch works, or fixes something?


-----Original Message-----
From: pgsql-jdbc-owner(at)postgresql(dot)org
[mailto:pgsql-jdbc-owner(at)postgresql(dot)org] On Behalf Of Ned Wolpert
Sent: Sunday, December 09, 2001 4:49 PM
To: pgsql-jdbc(at)postgresql(dot)org
Subject: Re: [JDBC] Bug with caching SQLTypes in

--- Antonio Fiol BonnĂ­n <fiol(at)w3ping(dot)com> wrote:
> Well, It is *certain* that the existing code is somehow broken. And it
> is visible even at first sight. How to correct it is probably harder, 

Yes, I noticed that too.  The 'quick/easy' fix that I'm using is to
update sqlTypeCache hashtable which mapped  'oid -> SQLType'. That was
the patch that I sent in.  It doesn't break anything 'more' since a) if
its not in cache it puts the value in the sqlTypeCache 
hashtable to begin with and b) if it is found in the check, then a 
potentially bogus result is returned. (Odds are it won't, since it
currently checks typeOidCache, which maps 'PGType -> oid' instead. I
doubt one would ever have an oid they send into the function, which 
would then check the typeOidCache.  The oid key wouldn't match the
PGType key to find the oid value.  Ugh... my brain hurts... ;-)

> but if you look into the following non abstract method, 
> getOID(String),
> you will see that it is looking up in the same hashtable, but using a 
> different class.

Yes. in getOID(String), it uses the typeOidCache correctly. (If the
comments defining the variable typeOidCache are correct.)  It maps the 
string of the PGType -> the Integer oid.

> In getSQLType(int), it is looking up an entry for an
> Integer. In getOID(String), it is looking up in the same hashtable,
> using a String. This is obviously wrong or a very bad programming 
> practice. (I vote wrong).

Yeah, I think it was just a mistake made that didn't give incorrect 
results since the item is never cached.  (Or, can never be found.)

> I can't go much deeper by now. Sorry.

Thanks, you've given me the info I need on the original discussion. I
think we should see if we can put this fix in before 7.2 is released.
Perchance in the 7.2rc1?  Folks?  Can someone else verify that our
analysis is correct before the rc1 release?

Virtually,        |                   "Must you shout too?" 
Ned Wolpert       |                                  -Dante
wolpert(at)yahoo(dot)com |             
_________________/              "Who watches the watchmen?"
4e75                                       -Juvenal, 120 AD

-- Place your commercial here --                      fnord

Do You Yahoo!?
Send your FREE holiday greetings online!

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

In response to


pgsql-jdbc by date

Next:From: Ned WolpertDate: 2001-12-10 19:49:11
Subject: Update for bug in org.postgresql.Connection method getSQLType(int)
Previous:From: Dave CramerDate: 2001-12-10 19:41:06
Subject: Re: inet -java

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