Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg

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.