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

Kris Jurka wrote:
>
> On Thu, 28 Oct 2004, Oliver Jowett wrote:
>
>
>>For PGobject it turned into a bit of a general overhaul. Currently I have:
>
>
> These changes are way too drastic for something as minor as preventing a
> user from accidentally mutating a NULL PGobject.

That wasn't really my motivation. It was a general cleanup of PGobject
and subclasses. The current implementations leave something to be desired.

> These API changes suck
> for both developers and users. There's no way to make a PGobject
> implementation compile against both 7.4 and 8.0 drivers. Altering the
> PGline API means user code can't compile against both 7.4 and 8.0 drivers.

The feedback I got earlier was that changing the PGobject API wasn't a
big deal and that external users of the API (which seems to boil down to
PostGIS & co only) would just track the changes. Is this not true?

> If we were providing exciting new features, then maybe, but for now we've
> got to find a way to make this work without huge API changes or we should
> abandon the whole idea and go back to your original patch. What
> immediately comes to mind is making the PGobject interface an abstract
> class with all abstract methods so that a developer can implement a type
> that can work with both driver versions.

That's possible. I'd almost prefer doing a new interface and having
PGobject be a completely-abstract implementation of it. Having the
driver-required bit as an interface makes it much easier to integrate
into whatever representation of the data is convenient to the application.

This might be moot if we look at a mapping mechanism that is external to
the data objects themselves, as suggested by Markus.

Either way, I can't really justify spending much more time on this: we
don't use extension types in our code at all, and there is still an
(admittedly ugly) way to set NULL values for extension types in the
existing driver.

-O