Re: Speed dblink using alternate libpq tuple storage

Hello, This is a new version of the patch formerly known as
'alternative storage for libpq'.

- Changed the concept to 'Alternative Row Processor' from
  'Storage handler'. Symbol names are also changed.

- Callback function is modified following to the comment.

- From the restriction of time, I did minimum check for this
  patch. The purpose of this patch is to show the new implement.

- Proformance is not measured for this patch for the same
  reason. I will do that on next monday.

- The meaning of PGresAttValue is changed. The field 'value' now
  contains a value withOUT terminating zero. This change seems to
  have no effect on any other portion within the whole source
  tree of postgresql from what I've seen.


> > I would like to propose better one-shot API with:
> > 
> >     void *(*RowStoreHandler)(PGresult *res, PGresAttValue *columns);
...
> > 1) Pass-through processing do not need to care about unnecessary
> >    per-row allocations.
> > 
> > 2) Handlers that want to copy of the row (like regular libpq),
> >    can optimize allocations by having "global" view of the row.
> >    (Eg. One allocation for row header + data).

I expect the new implementation is far more better than the
orignal.

regargs,

-- 
Kyotaro Horiguchi
NTT Open Source Software Center