Edmund,
I certainly respect your opinions and take note. We have used your
DBD::Pg-module
in several projects here with great success.
This is the conclusions I have reach:
* A "pure perl"-interface is useful for
- systems without decent C-compiler
- systems not supported by libpq
(there is already a pure TCL interface, isn't it?)
- in other special applications where "pure perl" is preferable.
* I will release my module, probably called PgSQL since,
- I need a "pure perl" interface for a couple of project
- The basic module is mostly done already
- Why not share?
* I will *NOT* make a DBD interface, because
- I don't need it
- the C-code in DBI make the arguments for "pure perl" mute
- It would confuse J. Random Looser and friends :-)
As I see it there is a niche for all three perl interfaces:
* DBI/DBD::Pg:
excellent portability across RDBMSs and nice standard API
makes it the natural choise for most project.
* Pg:
the choice where low-level access and maximum performance is needed
* PgSQL:
"pure perl" with OO-design makes it easily customizable for
PostgreSQL-only applications.
Maybe I will look at thread-safety for DBI/DBD::Pg/libpq but
debugging C-based perl-modules is pretty time consuming
(I wrote the DBD::Informix4 module a couple of yeasr ago).
Combine that with threads/debugging headache and isn't
so funny anymore. :-)
regards,
--
---------------------------------------------
Göran Thyni, sysadm, JMS Bildbasen, Kiruna
---------------------------------------------------------------
Edmund Mergl wrote:
> I suggest to spend the effort on making libpq thread safe.
> Otherwise we end up with two DBD modules for postgres.
> If you prepare a module, which does not depend on libpq,
> you will have much more effort on keeping it up to date.
> The main goal of an interface like libpq is to avoid such
> dependencies.