Re: [HACKERS] 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
>
>