Thread: best postgres interface

best postgres interface

From
Eric Enockson
Date:
    I see there are a couple of perl interfaces to
postgres.  Does anyone have any comments as to the
best?  I would prefer to use perl but if people
think is this the wrong way to go i would like
to know.

    Thanks in advance
    Eric enockson

Re: [INTERFACES] best postgres interface

From
"j. eidsness"
Date:
On Wed, 24 Mar 1999, Eric Enockson wrote:

=
=     I see there are a couple of perl interfaces to
= postgres.  Does anyone have any comments as to the
= best?  I would prefer to use perl but if people
= think is this the wrong way to go i would like
= to know.
=
=     Thanks in advance
=     Eric enockson

    I cannot tell you what the 'best' interface is, but i can tell you
that *I* use perl (mostly cause i dunno C or C++) and it works fine. It's
very flexible and returns tuples in a very managable manner. So far i have
no reason to knock it, other than the fact that you application is already
writeen in some other language (or you jus hate perl :)


[ ======================= jeff eidsness = ]
[ = webmaster =========================== ]
[ ===== http://www.wolfen.com/calendar/ = ]


Re: [INTERFACES] best postgres interface

From
"D'Arcy" "J.M." Cain
Date:
Thus spake j. eidsness
> =     I see there are a couple of perl interfaces to
> = postgres.  Does anyone have any comments as to the
> = best?  I would prefer to use perl but if people
> = think is this the wrong way to go i would like
> = to know.
>
>     I cannot tell you what the 'best' interface is, but i can tell you
> that *I* use perl (mostly cause i dunno C or C++) and it works fine. It's
> very flexible and returns tuples in a very managable manner. So far i have
> no reason to knock it, other than the fact that you application is already
> writeen in some other language (or you jus hate perl :)

I don't like Perl myself.  I used to use Tcl which has an interface in the
tree as well but since I discovered Python I'm using that almost exclusively.
The interface to it is also in the tree or information can be found at
http://www.druid.net/pygresql/.

--
D'Arcy J.M. Cain <darcy@{druid|vex}.net>   |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 424 2871     (DoD#0082)    (eNTP)   |  what's for dinner.

Re: [INTERFACES] best postgres interface

From
"Gene Selkov Jr."
Date:
>     I see there are a couple of perl interfaces to
> postgres.  Does anyone have any comments as to the
> best?  I would prefer to use perl but if people
> think is this the wrong way to go i would like
> to know.
>

I can only speak about the Pg interface that I am using. The second
one you mentioned is probably DBI::*; I am not familiar with it but it
looks similar. You might consider DBI if you client needs to access
other data sources as well and if you want it to be more portable. As
far as perl vs. others, I guess all interfaces send the queries and
handle results in much the same way. However, by simply being in
perl, you have and added value of being able to process the results in
a very sophisticated manner. If you choose perl, you won't find
yourself among those who complain about the backend not being able to
compute an avg() of something or not getting the date in the format
they please. Also, some of the tasks that still represent a
considerable load on the backend can be trivially solved in perl.

--Gene



Re: [INTERFACES] best postgres interface

From
"Gene Selkov, Jr."
Date:
>     I see there are a couple of perl interfaces to
> postgres.  Does anyone have any comments as to the
> best?  I would prefer to use perl but if people
> think is this the wrong way to go i would like
> to know.
>

I can only speak about the Pg interface that I am using. The second
one you mentioned is probably DBI::*; I am not familiar with it but it
looks similar. You might consider DBI if you client needs to access
other data sources as well and if you want it to be more portable. As
far as perl vs. others, I guess all interfaces send the queries and
handle results in much the same way. However, by simply being in
perl, you have and added value of being able to process the results in
a very sophisticated manner. If you choose perl, you won't find
yourself among those who complain about the backend not being able to
compute an avg() of something or not getting the date in the format
they please. Also, some of the tasks that still represent a
considerable load on the backend can be trivially solved in perl.

--Gene