installing DBD::Pg without installing postgres

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

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.

On Tue, 24 Apr 2001, Clayton Vernon wrote:

seems to be treating 'threadid' as numeric, not alpha.
did you run any macros that needed to guess the format of the field? many of
these are very poor in terms of looking down the table. sometimes the first
row can inadvertently define things for you.

Nope, to my knowledge nothing is going on except for normal INSERTs
and SELECTs. What confuses me is that 'threadid' is of type text, and even
if it were being treated as if it were of type numeric, its results are
still inconsistent, and somewhat inscrutable.

I can't see any reasonable way that this sorting:

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)

...would be occuring, unless it's going out of its way to try to strip
non-numeric characters and treat the remaining assembled numbers as a
whole number to sort by, possibly?

But if that were the case, that still doesn't explain why the substrings
(below) behave the way that they do, in re-ordering the underscores.

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)

Thanks, though still puzzled,
Jw @ Command Prompt.
--
By way of pgsql-general@commandprompt.com

Dunno if this is helpful, but there is a pattern.

After stripping off the leading non-numeric characters, from the results
in the previous email, this leaves :

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)

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)

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)

As for why? Don't know.

But the sorting is consistent.

Regards and best wishes,

Justin Clift

pgsql-general@commandprompt.com wrote:

On Tue, 24 Apr 2001, Clayton Vernon wrote:

seems to be treating 'threadid' as numeric, not alpha.
did you run any macros that needed to guess the format of the field? many of
these are very poor in terms of looking down the table. sometimes the first
row can inadvertently define things for you.

Nope, to my knowledge nothing is going on except for normal INSERTs
and SELECTs. What confuses me is that 'threadid' is of type text, and even
if it were being treated as if it were of type numeric, its results are
still inconsistent, and somewhat inscrutable.

I can't see any reasonable way that this sorting:

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)

...would be occuring, unless it's going out of its way to try to strip
non-numeric characters and treat the remaining assembled numbers as a
whole number to sort by, possibly?

But if that were the case, that still doesn't explain why the substrings
(below) behave the way that they do, in re-ordering the underscores.

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)

Thanks, though still puzzled,
Jw @ Command Prompt.
--
By way of pgsql-general@commandprompt.com

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)

--
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi

<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

The behavior seen here seems correct although not intuitive. My guess
is that your database executables where created with locale support
enabled and your database was inited with a US locale. The sorting
logic for the english locales only sort on alpha-numeric characters.
All other characters are ignored for sorting purposes.

So these values:

000-0987877374-00313
___-0987877410-00316
___-0987877430-00317
100-0987877381-00314
100-0987877395-00315
200-0987877461-00318
get sorted as:

000098787737400313
098787741000316
098787743000317
100098787738100314
100098787739500315
200098787746100318
thus you see it is sorted correctly. If you look at all of the other
examples you will see this explains all of the results you are seeing.

What I think you really want here is a binary sort order, not a locale
specific sort order. So you should initdb your database with a locale
of C, or rebuild postgresql without locale support enabled.

I think there is a contrib program that you can use to see what locale
your database was created with. Once your database is created you can't
change the locale, you will need to re-initdb.

thanks,
--Barry

Justin Clift wrote: