In the JDBC binding, why is PGobject a class instead of an interface?

This is a moot issue when creating a type from scratch, but Java
contains a large number of standard classes (not interfaces) for
PKIX objects so I'm in a bind when trying to create my own JDBC
extensions. 

Specifically, some of the key mappings (no pun intended) are:

  hugeint   <-> java.language.BigInteger
  principal <-> java.security.Principal
  x509      <-> java.security.cert.X509Certificate
  x509_crl  <-> java.security.cert.X509CRL

and some additional metamappings between pkcs8 and java.security.KeyStore.

I can implement the mapping by casting between the objects and text,
but if a type extension mechanism is available it would be nice to be
able to hide those details from the user.



Sun, 6 Jan 2002 17:00:35 -0700 (MST)
Bear Giles <bear@coyotesong.com>
JDBC: why is PGobject class instead of interface?
On Sun, Jan 06, 2002 at 05:00:35PM -0700, Bear Giles wrote:
> I can implement the mapping by casting between the objects and text,
> but if a type extension mechanism is available it would be nice to be
> able to hide those details from the user.

The type extension mechanism inherent in JDBC is provided by an
implementation of java.sql.Connection.setTypeMap(Map map) and related
methods. The PostgreSQL JDBC driver has not yet got this feature. I
think it would be fine if somebody would add this to PostgreSQL ;-)

-- 
Holger Krug
hkrug@rationalizer.com

Tue, 8 Jan 2002 16:11:24 +0100
Holger Krug <hkrug@rationalizer.com>
Re: JDBC: why is PGobject class instead of interface?
Bear,

This question is probably better addressed to the pgsql-jdbc mail list 
than the hackers mail list.

I don't exactly understand what you are trying to do from your 
description, but let me try to explain what I think you are trying to do.

You want to extend the database and jdbc to support additional datatypes 
(java's BigInteger for example).  In jdbc you then want to return from a 
getObject() call an object that is compatible with the underlying java 
object.  Currently the way you add support in the jdbc driver to new 
datatypes is to subclass PGobject (that is how money is supported for 
example).  The problem with this approach is that because java doesn't 
have multiple inheritance, the object can't both extend PGobject and the 
real underlying java object (BigInteger for example).  If PGobject were 
an interface then you could create a PGBigInterger object that 
implemented PGobject and extended BigInteger, such that the calling 
program could use the object as a BigInteger object.

Is this a correct understanding of your problem with PGobject?

I don't know of any reason PGobject needs to be a concrete class.  I 
beleive it could be an interface.  But this isn't an area of the code I 
have spent a lot of time looking at, so I may be wrong.

thanks,
--Barry



Bear Giles wrote:

> In the JDBC binding, why is PGobject a class instead of an interface?
> 
> This is a moot issue when creating a type from scratch, but Java
> contains a large number of standard classes (not interfaces) for
> PKIX objects so I'm in a bind when trying to create my own JDBC
> extensions. 
> 
> Specifically, some of the key mappings (no pun intended) are:
> 
>   hugeint   <-> java.language.BigInteger
>   principal <-> java.security.Principal
>   x509      <-> java.security.cert.X509Certificate
>   x509_crl  <-> java.security.cert.X509CRL
> 
> and some additional metamappings between pkcs8 and java.security.KeyStore.
> 
> I can implement the mapping by casting between the objects and text,
> but if a type extension mechanism is available it would be nice to be
> able to hide those details from the user.
> 
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
> 
> 



Tue, 08 Jan 2002 10:51:12 -0800
Barry Lind <barry@xythos.com>
Re: [HACKERS] JDBC: why is PGobject class instead of interface?