internal type cache, and getUDT implementation

From: Dave Cramer <pg(at)fastcrypt(dot)com>
To: "pgsql-jdbc(at)postgresql(dot)org" <pgsql-jdbc(at)postgresql(dot)org>
Subject: internal type cache, and getUDT implementation
Date: 2004-05-21 13:37:43
Message-ID: 1085146663.1687.52.camel@localhost.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

I've been working on getUDT's and in order to fully comply with the
spec, java.sql.Types.* has to be returned for the base type in the case
of a domain.

This requires quite a big select statement, which essentially does a
case 'char' then java.sql.VARCHAR.... attached is the patch for this.

However at one time I considered translating the returned value in the
result set. This required that I knew the pg_type oid for each type in
advance. Currently the driver gets and cache's these in a static hashmap
as it requires them.

This is either inefficient or flawed depending on the way you look at
it.

Flawed: The assumption here is that we don't know the type oid's in
advance and that the backend might change them. If this is the case and
the driver happens to be connected to two different versions ( with
different pg_type oid's ) of backends, then one of them will be wrong,
as the cache is static.

Inefficient: I've asked on hackers and they are willing to guarantee
that type oid's won't change, so why bother looking them up ?

Dave

--
Dave Cramer
519 939 0336
ICQ # 14675561

Attachment Content-Type Size
UDT.patch text/x-patch 14.7 KB

Browse pgsql-jdbc by date

  From Date Subject
Next Message Tom Lane 2004-05-21 14:30:37 Re: Queries with large ResultSets
Previous Message Oliver Jowett 2004-05-21 11:38:53 Re: Queries with large ResultSets