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 |
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 |