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

From: Ned Wolpert <wolpert(at)yahoo(dot)com>
To: pgsql-jdbc(at)postgresql(dot)org
Subject: Re: Bug with caching SQLTypes in Connection:getSQLType(oid)
Date: 2001-12-09 21:48:36
Message-ID: 20011209214836.34363.qmail@web13407.mail.yahoo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

--- Antonio Fiol Bonnn <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, 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(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!
http://greetings.yahoo.com

Responses

Browse pgsql-jdbc by date

  From Date Subject
Next Message PANOS Coup 2001-12-10 08:08:16 inet -java
Previous Message Rene Pijlman 2001-12-09 17:21:08 Re: JDBC 3.0 / JDK 1.4 build issues