Digioso has asked for the wisdom of the Perl Monks concerning the following question:

Hi Monks, I have a website on a webhoster that offers PostgreSQL databases.
Unfortunately it's just webspace so I don't have any access to the underlying OS or root-access. And the DBD::Pg module is not installed. I contacted my webhoster and asked them to install it but so far they seem to be unwilling to do so. The last statement from them was: PHP is used more often than Perl so please think about using PHP.
That wasn't really a helpful answer for me...

Often it is enough to just upload the appropiate .pm files to your own module library but this doesn't work for DBD::Pg.

I am able to run the psql command and have tested this, though. This allows me to run queries and so on. This is the only alternative I came up with so far.
I'd write myself a wrapper-function for the psql-command which I can use in my other scripts. But if possible I want to avoid that since the DBI-module pretty much is what I have used since years.

So my question is: Are there alternatives to DBD::Pg? Or is there some way to use DBD::Pg without having to install it?

Thanks in advance,

Digioso.

Replies are listed 'Best First'.
Re: Alternative to DBD::Pg
by Corion (Patriarch) on Jan 31, 2016 at 10:56 UTC

    The easiest solution could be DBD::PgPP (as found via pure perl Postgres).

    The medium solution is to find a better webhoster.

    The harder solution is to either find that they have the appropriate C compiler installed, to install your own C compiler or to replicate their environment and then to compile DBD::Pg yourself.

      Thanks a lot! :)
      PgPP is exactly what I was looking for.
      Just uploading the .pm file is enough. No installation needed.
Re: Alternative to DBD::Pg
by hippo (Archbishop) on Jan 31, 2016 at 15:04 UTC
    I contacted my webhoster and asked them to install it but so far they seem to be unwilling to do so. The last statement from them was: PHP is used more often than Perl so please think about using PHP.

    Option 1: name and shame them here so we all know to avoid them in future.

    Option 2: reply to them saying "AWS is used more often than you so I'm thinking about using AWS instead".

    Glad to see you now have a workaround to this particular problem, however.