Re: Alternative new libpq interface.

Marten Feldtmann wrote:
>
> On Thu, 06 Jul 2000 15:50:13 +1000, Chris Bitmead wrote:
>
> >
> >My idea is that there should be a very low level interface that has a
> >minimum of bloat and features and caching and copying. This would be
> >especially nice for me writing an ODMG interface because the ODMG
> >interface would be needing to cache and copy things about so having
> >libpq doing it too is extra overhead. It could also form the basis of
> >a trivial re-implementation of the current libpq in terms of this
> >interface.
>
> What does it mean: ODMG interface. I've the ODMG 3.0 book in front
> of me and i do not know, what you would like to create ... why is
> caching and copying a need for ODMG ???

Each programming language has a specified ODMG interface. Database
objects are mapped 1:1 with language objects. Every time you read
a database object a language object is created to represent it.

Now if you read the same database object in different places in your
code. Maybe the same object is "navigated" to via different paths,
you don't want two objects created in memory to represent that object.
If that happened you could have a confusing integrity situation.

So with an ODMG interface it keeps track of what database objects
are in memory at any one time - think of it as a cache, and makes
sure that if you request the same object again, it doesn't construct
a new one but returns the existing one.

Of course when you create one of these language objects, the values
must be copied into the fields of the object. That's where the copying
comes in. Now some object databases are implemented by just transferring
whole database pages to the client side. Obviously they have pretty low
overhead in terms of memory copying data from one place to another. A
postgres style architecture _can_ compete with this, but I suspect
it must try harder in libpq in terms of how many times a bit of
memory coming in is copied around the place. (Or maybe not. Maybe that
is premature optimisation).