Thread: installing DBD::Pg without installing postgres
Hello, It seems that there should be a way to install the DBD Pg module without having to install postgres on the local machine. I tried installing just the libs rpm, but that didn't seem to do the trick. I've done some usenet and mailing list archive searches, but all the info I'm turning up appears geared towards the assumption that you also want postgres installed locally. Am I looking in the wrong places? Thanks, Fran
Fran Fabrizio wrote: > > Hello, > > It seems that there should be a way to install the DBD Pg module without > having to install postgres on the local machine. I tried installing > just the libs rpm, but that didn't seem to do the trick. I've done some What's the dependencies for the DBD::Pg RPM? Satisfy those dependencies, and properly set up for client-server communications with a postgresql server, and it _should_ just _work_. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
> What's the dependencies for the DBD::Pg RPM? Satisfy those > dependencies, and properly set up for client-server communications with > a postgresql server, and it _should_ just _work_. Well, if I had known what it took to satisfy the dependencies, I wouldn't have needed to post here. ;-) It was looking for a libpg-fe.h. This file does not appear to be in the libs rpm, which is the only thing I can install without needing to download the entire source. In the interest of a quicker resolution, I just went ahead and installed postgres. I had to install the libs rpm, then the postgres rpm itself, then the devel rpm in order to find the file. Since the devel depends on postgres itself, I did have to install postgres in order to install DBD Pg. Which seems wrong somehow. libpg-fe.h seems to be available from two places: in the source .tar.gz in the interfaces/ subdir, or in the devel rpm, which requires the source rpm. So either way, you have to grab the source in one form or another. Oh well. I just hoped that there was a libs rpm or .tar.gz that would allow me to build these other tools without requiring the eitire source of postgres itself. Maybe my hopes are misguided. =) Thanks, Fran
On Monday 23 April 2001 06:04 pm, Lamar Owen wrote: > Fran Fabrizio wrote: > > Hello, > > > > It seems that there should be a way to install the DBD Pg module without > > having to install postgres on the local machine. I tried installing > > just the libs rpm, but that didn't seem to do the trick. I've done some > > What's the dependencies for the DBD::Pg RPM? Satisfy those > dependencies, and properly set up for client-server communications with > a postgresql server, and it _should_ just _work_. I don't know a lot of detail about how DBD::Pg works, but I do know that during installation (whether from tarball or CPAN, which I think is the best way to install perl modules), it requires the path of your postgres libraries and includes - so I guess it depends on a postgres installation on the local machine. What are you trying to accomplish, exactly? Michelle ------------ Michelle Murrain, Ph.D. President Norwottuck Technology Resources mpm@norwottuck.com http://www.norwottuck.com
> I don't know a lot of detail about how DBD::Pg works, but I do know that > during installation (whether from tarball or CPAN, which I think is the > best way to install perl modules), it requires the path of your postgres > libraries and includes - so I guess it depends on a postgres > installation on the local machine. > > What are you trying to accomplish, exactly? Well, one thing (that I can think of) would be to have multiple webservers (without postgres) connecting to a central DB server. I would've run into this in a couple of weeks, actually, so I'm glad someone else found out about it first. :) I think functionality to retrieve the necessary libs ought to be built into the installation of DBD::Pg to facilitate just such a situation... John -- # John Madden weez@freelists.org ICQ: 2EB9EA # FreeLists, Free mailing lists for all: http://www.freelists.org # UNIX Systems Engineer, Ivy Tech State College: http://www.ivy.tec.in.us # Linux, Apache, Perl and C: All the best things in life are free!
At 04:30 PM 23-04-2001 -0400, Fran Fabrizio wrote: > >Hello, > >It seems that there should be a way to install the DBD Pg module without >having to install postgres on the local machine. I tried installing >just the libs rpm, but that didn't seem to do the trick. I've done some >usenet and mailing list archive searches, but all the info I'm turning >up appears geared towards the assumption that you also want postgres >installed locally. Am I looking in the wrong places? My guess for installing DBD for any database is you at least need a client install - libraries, headers. But postgresql is actually quite easy to install, doesn't take tons of space, plus there's no cost or licensing problem, so I just install the whole thing. Whereas I had a tough time installing DBD for Oracle a couple of years ago. Cheerio, Link.
On Mon, 23 Apr 2001 16:30:43 -0400, Fran Fabrizio alluded: > > Hello, > > It seems that there should be a way to install the DBD Pg module without > having to install postgres on the local machine. I tried installing > just the libs rpm, but that didn't seem to do the trick. I've done some > usenet and mailing list archive searches, but all the info I'm turning > up appears geared towards the assumption that you also want postgres > installed locally. Am I looking in the wrong places? There really isn't any reason to do so. If you're looking to have many machines connect to a single PostgreSQL database, take a look at DBI::Proxy. It is designed to allow you to connect to databases that have libraries linked into the DBD::* executables without needing the libraries on the local box (this is very nice for avoiding the Oracle client library installs as well). Jeff
Michelle & John> Yes, that's exactly what I am trying to accomplish. I am setting up a network monitoring application for our support personnel, and I have multiple people all examining data that gets reported to a central database. So I didn't relish the idea of installing postgres on all of the support personnel workstations. Jeff> Thanks for the tip about DBI::Proxy. That seems to be the missing link, as I've also run into this problem with MySQL in addition to Postgres. MySQL does have a libs-only rpm that you can use for installing the MySQL DBD without having MySQL locally, but DBI::Proxy may be an even cleaner solution. Thanks everyone for the dialogue, it has been very useful! -Fran
Good day,
We've run into a strange bit of sorting behavior with the new release of
PostgreSQL 7.1. Specifically, we have some text that we're using as
threadids in a discussion board, which look like the following example:
threadid
----------------------
000-0987877374-00313
___-0987877410-00316
___-0987877430-00317
100-0987877381-00314
100-0987877395-00315
200-0987877461-00318
The signifigance of the numbers is secondary to the alphanumeric sorting
of them. You can see above that the first three characters are either
numeric or underscores. We were using the underscores as a means to force
"unrated" threads to be sorted after rated threads, and with PostgreSQL
7.0.3, and with some CVS snapshots for 7.1, it worked fine! If I performed
the query:
lxp=# SELECT threadid FROM test ORDER BY threadid;
I'd get:
threadid
----------------------
000-0987877374-00313
100-0987877381-00314
100-0987877395-00315
200-0987877461-00318
___-0987877410-00316
___-0987877430-00317
However, at some point between the last snapshot we grabbed (several weeks
ago) and the release of 7.1, this behavior has changed. If I do the same
sort now, I get:
lxp=# SELECT threadid FROM test ORDER BY threadid;
threadid
----------------------
000-0987877374-00313
___-0987877410-00316
___-0987877430-00317
100-0987877381-00314
100-0987877395-00315
200-0987877461-00318
(6 rows)
At first blush, it seems that it's somehow coming to the conclusion that
the underscore alphanumerically follows the 0, and preceds the 1. (?!)
However, that's not the end of it! Observe this unpredictable behavior
with ordering by substrings:
lxp=# SELECT substr(threadid,1,5) FROM test ORDER BY substr(threadid, 1, 5);
substr
--------
___-0
___-0
000-0
100-0
100-0
200-0
(6 rows)
Now, the underscores appear to PRECEDE the 0's. This seems at least a
little more sane, however this is completely the opposite of where the
underscore would be sorted with 7.0.3. Now consider the next substring, of
six characters instead of five.
lxp=# SELECT substr(threadid,1,6) FROM test ORDER BY substr(threadid, 1, 6);
substr
---------
000-09
___-09
___-09
100-09
100-09
200-09
(6 rows)
Back to the underscores fitting between 0 and 1 again, simply by adding
a 9 to the end of the ids. Logically, I'm at a loss for why this should be.
I've already re-factored my system to use purely numeric values for
sorting, because it was impairing the capability of our message boards to
be properly sequenced, but I was interested in knowing whether or not this
is a bug, a change in the way PostgreSQL sorts, or possibly some kind of
locale-specific misconfiguration?
Any insight would be appreciated,
Jw @ Command Prompt.
--
By way of pgsql-general@commandprompt.com.
<pgsql-general@commandprompt.com> writes:
> I was interested in knowing whether or not this
> is a bug, a change in the way PostgreSQL sorts, or possibly some kind of
> locale-specific misconfiguration?
There is not any (intentional) change in sorting behavior between 7.1
and earlier releases; indeed, since the sort order of text fields is
determined by libc's strcmp() or strcoll(), it would be pretty hard for
us to change it if we wanted to. My money is on a locale issue ...
although the sorting behavior you describe doesn't seem to match any
commonly used locale.
Things to try:
Check whether you built with locale and/or multibyte support (and did
you make the same choices before?).
Use the contrib/pg_controldata program to see what locale the database
is initialized in.
Run the regression tests, both "make check" (which should force C
locale) and "make runtest" (which will talk to your installed postmaster
and hence use whatever locale it's using). I'd not be surprised to get
some ordering differences in the runtest results.
regards, tom lane