Re: Shared Objects (Dynamic loading) - Mailing list pgsql-general

From Jasbinder Bali
Subject Re: Shared Objects (Dynamic loading)
Date
Msg-id a47902760608272229r10f4afdfkd09a15e4b7a9e0e4@mail.gmail.com
Whole thread Raw
In response to Re: Shared Objects (Dynamic loading)  (Michael Fuhr <mike@fuhr.org>)
Responses Re: Shared Objects (Dynamic loading)  (Martijn van Oosterhout <kleptog@svana.org>)
Re: Shared Objects (Dynamic loading)  (Gerald Timothy G Quimpo <gerald.quimpo@qualservcentral.com>)
List pgsql-general
Just wondering why would i need libpq here.
Doesn't DBD::pg has its own functions for database related activities.
I think i'm quite naive in this.

Also, the triggers that i wrote in C are not all that elaborative. They are pretty basic triggers. Also, I'm a rookie in perl but don't need to do something hifi with it.

Thanks,
~Jas

On 8/28/06, Michael Fuhr <mike@fuhr.org> wrote:
On Sun, Aug 27, 2006 at 09:41:39PM -0400, Jasbinder Bali wrote:
> The actual scenario is like my perl code is on one computer and database
> server is on the other computer. The perl code needs to connect to that
> database server residing on a diff computer.
>
> I think client machine should also have DBI module in it. right?

Right.  The client machine needs DBI (the database-independent
module), DBD::Pg (the PostgreSQL-specific driver), and libpq (the
PostgreSQL client library).

> Also, how much of a change would it be if i have to migrate my triggers
> and functions written for C to Perl

That depends on how many triggers you have, how elaborate they are,
and how proficient you are at Perl.  I tend to use PL/pgSQL for
functions that involve a lot of SQL statements; I use PL/Perl or
PL/Ruby for things like text manipulation that those languages are
good at.

--
Michael Fuhr

pgsql-general by date:

Previous
From: "Harpreet Dhaliwal"
Date:
Subject: Perl language creation failed
Next
From: "A. Kretschmer"
Date:
Subject: Re: Perl language creation failed