Thread: installing DBD::Pg without installing postgres

installing DBD::Pg without installing postgres

From
Fran Fabrizio
Date:
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


Re: installing DBD::Pg without installing postgres

From
Lamar Owen
Date:
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

Re: installing DBD::Pg without installing postgres

From
Fran Fabrizio
Date:
> 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





Re: installing DBD::Pg without installing postgres

From
Michelle Murrain
Date:
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

Re: installing DBD::Pg without installing postgres

From
John Madden
Date:
> 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!

Re: installing DBD::Pg without installing postgres

From
Lincoln Yeoh
Date:
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.


Re: installing DBD::Pg without installing postgres

From
"Jeff Duffy"
Date:
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

Re: installing DBD::Pg without installing postgres

From
Fran Fabrizio
Date:
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


Question on Bizarre Sorting (ORDER BY in 7.1)

From
Date:
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.


Re: Question on Bizarre Sorting (ORDER BY in 7.1)

From
Tom Lane
Date:
<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