Re: Bug with caching SQLTypes in Connection:getSQLType(oid) - Mailing list pgsql-jdbc

From Ned Wolpert
Subject Re: Bug with caching SQLTypes in Connection:getSQLType(oid)
Date
Msg-id 20011209214836.34363.qmail@web13407.mail.yahoo.com
Whole thread Raw
In response to Bug with caching SQLTypes in Connection:getSQLType(oid)  (Ned Wolpert <ned.wolpert@knowledgenet.com>)
Responses Re: Bug with caching SQLTypes in Connection:getSQLType(oid)
List pgsql-jdbc
--- Antonio Fiol Bonn�n <fiol@w3ping.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, but
> 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@yahoo.com |
_________________/              "Who watches the watchmen?"
4e75                                       -Juvenal, 120 AD

-- Place your commercial here --                      fnord

__________________________________________________
Do You Yahoo!?
Send your FREE holiday greetings online!
http://greetings.yahoo.com

pgsql-jdbc by date:

Previous
From: Barry Lind
Date:
Subject: Re: patch against cvs for getTimestamp() problem.
Next
From: "PANOS Coup"
Date:
Subject: inet -java