Skip site navigation (1) Skip section navigation (2)

PGobject overhaul (was Re: tightening up on use of oid 0)

From: Oliver Jowett <oliver(at)opencloud(dot)com>
To: Kris Jurka <books(at)ejurka(dot)com>
Cc: "pgsql-jdbc(at)postgresql(dot)org" <pgsql-jdbc(at)postgresql(dot)org>
Subject: PGobject overhaul (was Re: tightening up on use of oid 0)
Date: 2004-10-28 02:18:13
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-jdbc
Kris Jurka wrote:
> On Thu, 14 Oct 2004, Oliver Jowett wrote:
>   [... PGobject and NULL ...]
>>It's hardly ideal but it kept the changes to a minimum. If you don't 
>>mind a more invasive set of changes, I can probably come up with 
>>something better.
> Yes, let's think about this a little more.  I unfortunately don't have any 
> brilliant ideas, perhaps just adding a boolean everywhere is simplest.

I've applied the non-PGobject bits of this patch.

For PGobject it turned into a bit of a general overhaul. Currently I have:

PGobject layer:

- PGobject becomes an interface
- Implementations of PGobject should provide a ctor taking a single 
String; this is called by the driver to construct non-null objects.
- PGobject.setType() and PGobject.setValue() go away entirely
- A new helper class, PGunknown, provides an immutable type+value 
implementation of PGobject (i.e. 'new PGunknown("mytype","myvalue")'). 
This gives the functionality currently available via PGobject.setType() 
/ setValue, and is used by the driver when it receives an unhandled type 
in a resultset.

PGobject subclasses:

- Generally, classes become immutable where it's easy to do (PGmoney, 
PGinterval, PGpoint, PGline, PGlseg, PGcircle, PGbox)
- PGpoint.translate() returns a new PGpoint rather than modifying the 
existing point (I'm not sure why this method even exists really..)
- Constant-sized PGpoint[] arrays in PGline, PGlseg, PGbox become 
separate fields; this makes immutability much easier.
- PGpolygon and PGpath remain mutable as it's hard to make them 
immutable without incurring lots of array copies.

- No-arg ctors construct NULL objects.
- PGmoney and PGpoint get boolean isNull fields, the other types reuse 
an existing reference field.
- equals(), hashCode(), getValue() take account of NULL-ness.
- Add per-class static NULL singleton fields for convenience; for 
mutable types, I'm not sure whether to just omit the singletons 
(slightly less convenient/readable), or to use PGunknown to get an 
immutable NULL (works, but 'instanceof' on NULL becomes misleading).

Much of the mutability changes here are just personal preference, 
they're not necessary to support NULLs but I thought I'd clean things up 
while I was in the area.

When we come to do binary-format types, I'd expect we would have a 
subinterface (PGbinaryobject?) that adds whatever methods are needed for 
binary parameter formatting. Objects that implement PGbinaryobject 
become candidates for binary transfer.

Any thoughts on this general approach?


In response to


pgsql-jdbc by date

Next:From: Giampaolo TomassoniDate: 2004-10-28 15:11:21
Subject: Serializable transactions and SQLException
Previous:From: Dave CramerDate: 2004-10-28 00:09:57
Subject: Re: JDBC CTS 1.2.1

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group