[Libpqxx-general] libpqxx issues

[Jeroen Vermeulen]

Christian von Kietzell wrote:
> Hi Jeroen,
> 
> I recently reported what I think is a bug in libpqxx (#199). So far
> I've not seen any activity on it (acknoledgement etc.). I know it was
> only yesterday, maybe I'm an impatient guy ;-)

I saw the bug report, but have had no time to give it the thought it 
deserves.  Something needed finishing urgently here in New Zealand.

I'll follow up on the ticket later tonight.


> I've read in other bug reports that you're short on time, so I wanted
> to ask if there is something I can do to help. I'm not only talking
> about this particular issue but libpqxx in general. Are you interested
> in patches for bug reports? Is there any area that is more important
> than the code itself? If there is anything I can do, just let me know.

That is always very welcome!  Of course I am interested.  The most 
urgent needs are, in this order:

  * Better building/installation on Windows.  But given that you deal 
with UTF-8, that is probably not your platform.  :-)

  * Date/time string conversions.  Dates are easy once you decide to 
stick with the Gregorian calendar, but that's where the easy choices 
stop.  This is an amazingly thorny subject.

  * Documentation and examples.  I think the reference docs are okay but 
new users want better documentation on getting started.  Integrating 
with the reference docs would be nice.

  * SSL connection setup, testing etc.

  * Array string conversions.  But not really worth doing without libpq 
support.

Unless you have some really good idea for dealing with time (and 
especially timezones, sigh) there's not much development work to be done 
on these subjects.  But there are other jobs:

  * 2-phase commit.  We did some design work for this ages ago but never 
implemented it.

  * Code cleanup.  In particular, it's about time to start removing 
workaround code and autoconf checks for ancient libpq versions.  I doubt 
anyone needs the next libpqxx release to support 8-year-old libpq releases.

  * API ideas for 4.0: different ways of going through a result set, 
more consistent naming of objects to help produce clearer error 
messages, maybe ideas for implementing binary data transfers without 
inhuman effort.

  * More systematic, readable unit tests.  The existing tests still tend 
towards "stories" and carry tables around.  I'd like to see them more 
independent.

  * A replacement for the old CachedResult: a random-access, 
self-optimizing, demand-fetched "mega result set."

If you have any ideas or needs, please bring them up here!


Jeroen