Perl DBD / DBI modules
I've recently compiled and put into service Posgresql v6.4. All is working
well.
I am looking for information on locating, compiling, and implementing a
Perl DBD or DBI for Postgresql. Can anyone assist?
Bob
I've used PostgreSQL before, but has just joined this mailing list
again after having searched www.postgresql.org for any information
about 6.4. There's no mention of what is news in 6.4 anywhere to be
found. Why not? What _is_ new?
On Fri, 4 Dec 1998, Bob Kruger wrote:
Just as with any other perl module:
/usr/local/bin/perl -MCPAN -e shell
install DBI
install DBD::Pg
#
# I've recently compiled and put into service Posgresql v6.4. All is working
# well.
#
# I am looking for information on locating, compiling, and implementing a
# Perl DBD or DBI for Postgresql. Can anyone assist?
#
# Bob
#
#
#
--
SA, beyond.com My girlfriend asked me which one I like better.
pub 1024/3CAE01D5 1994/11/03 Dustin Sallings <dustin@spy.net>
| Key fingerprint = 87 02 57 08 02 D0 DA D6 C8 0F 3E 65 51 98 D8 BE
L_______________________ I hope the answer won't upset her. ____________
I've used PostgreSQL before, but has just joined this mailing list
again after having searched www.postgresql.org for any information
about 6.4. There's no mention of what is news in 6.4 anywhere to be
found. Why not? What _is_ new?
See the TODO list on the support page, or see the HISTORY file in the
6.4 distribution.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026I studied the TODO list without finding these elements. How about
including then on the TODO list ?
1. Better money types. As it is now, it is unusable for large amounts,
because it really maps to an 4 byte integer. The best solution would be
to make the size configurable, but maybe it could do to make it 8 byte
integer?
2. An ALTER TABLE ALTER COLUMN new-type. Of course the will be a risk
of loosing information here, but that's the users problem if he eg.
want to convert a 50 character field to 30 character.
On a related topic, how far down the list is the row level locking? Will
it come in a not too distant release?
On Thu, 10 Dec 1998, Kaare Rasmussen wrote:
On a related topic, how far down the list is the row level locking? Will
it come in a not too distant release?
Vadim has already starting throwing in code for this...his plan is
for v6.5 release (~3months) for this to be in place...
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
On Thu, 10 Dec 1998, The Hermit Hacker wrote:
// Vadim has already starting throwing in code for this...his plan
// is for v6.5 release (~3months) for this to be in place...
Interesting...will this help out vacuuming any?
--
SA, beyond.com The world is watching America,
pub 1024/3CAE01D5 1994/11/03 Dustin Sallings <dustin@spy.net>
| Key fingerprint = 87 02 57 08 02 D0 DA D6 C8 0F 3E 65 51 98 D8 BE
L________________________________________ and America is watching TV. __
dustin sallings wrote:
On Thu, 10 Dec 1998, The Hermit Hacker wrote:
// Vadim has already starting throwing in code for this...his plan
// is for v6.5 release (~3months) for this to be in place...Interesting...will this help out vacuuming any?
No. Vacuum will still exclusively lock relation. But
I'll fix vacuum to unlock pg_class (when vacuuming all tables
in database).
And note - this will be not row level locking, but
multi-version concurrency control.
Vadim
I studied the TODO list without finding these elements. How about
including then on the TODO list ?1. Better money types. As it is now, it is unusable for large amounts,
because it really maps to an 4 byte integer. The best solution would be
to make the size configurable, but maybe it could do to make it 8 byte
integer?
TODO list has:
* Make MONEY/DECIMAL have a defined precision
2. An ALTER TABLE ALTER COLUMN new-type. Of course the will be a risk
of loosing information here, but that's the users problem if he eg.
want to convert a 50 character field to 30 character.
Added:
* Add ALTER TABLE DROP/ALTER COLUMN feature
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026Moved to -hackers...
On Thu, 10 Dec 1998, dustin sallings wrote:
On Thu, 10 Dec 1998, The Hermit Hacker wrote:
// Vadim has already starting throwing in code for this...his plan
// is for v6.5 release (~3months) for this to be in place...Interesting...will this help out vacuuming any?
My understanding that that is a seperate issue altogether, but I
may be wrong...
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
-----Original Message-----
From: owner-pgsql-general@postgreSQL.org
[mailto:owner-pgsql-general@postgreSQL.org]On Behalf Of Vadim Mikheev
Sent: Thursday, December 10, 1998 6:05 PM
To: dustin sallings
Cc: The Hermit Hacker; Kaare Rasmussen; pgsql-general@postgreSQL.org
Subject: Re: [GENERAL] TODO list elementsdustin sallings wrote:
On Thu, 10 Dec 1998, The Hermit Hacker wrote:
// Vadim has already starting throwing in code for this...his plan
// is for v6.5 release (~3months) for this to be in place...Interesting...will this help out vacuuming any?
No. Vacuum will still exclusively lock relation. But
I'll fix vacuum to unlock pg_class (when vacuuming all tables
in database).
And note - this will be not row level locking, but
multi-version concurrency control.
What does it mean ?
LLL in 6.5 doesn't include row level locking ?
Thanks.
Hiroshi Inoue
Inoue@tpf.co.jp
Hiroshi Inoue wrote:
And note - this will be not row level locking, but
multi-version concurrency control.What does it mean ?
LLL in 6.5 doesn't include row level locking ?
One systems (Informix, Sybase) use locking for concurrency control,
another ones (Oracle, Interbase) use multi-versioning for this.
I'm implementing multi-version concurrency control.
Vadim
-----Original Message-----
From: root@dune.krs.ru [mailto:root@dune.krs.ru]On Behalf Of Vadim
Mikheev
Sent: Monday, December 14, 1998 5:03 PM
To: Hiroshi Inoue
Cc: The Hermit Hacker; pgsql-general@postgreSQL.org
Subject: Re: [GENERAL] TODO list elementsHiroshi Inoue wrote:
And note - this will be not row level locking, but
multi-version concurrency control.What does it mean ?
LLL in 6.5 doesn't include row level locking ?One systems (Informix, Sybase) use locking for concurrency control,
another ones (Oracle, Interbase) use multi-versioning for this.
I'm implementing multi-version concurrency control.
My words might be obscure.
What I meant was
How writers block other writers in LLL ?
Certainly readers block no writers(readers) in LLL.
But writers block no writers or the same-row writers or the same-table
writers ?
Currently writers block the same-table writers(readers also) ?
Thanks.
Hiroshi Inoue
Inoue@tpf.co.jp
Hiroshi Inoue wrote:
My words might be obscure.
What I meant was
How writers block other writers in LLL ?
Certainly readers block no writers(readers) in LLL.
But writers block no writers or the same-row writers or the same-table
writers ?Currently writers block the same-table writers(readers also) ?
Only same-row writers will be blocked.
Vadim
Anyone working on Row level locking and
on-line recovery?
I have some ideas (and questions) in this area.
Also, I was wondering if there is a "transaction
server" project, i.e., a server that helps provide
a consistent client interface to both the database and
application servers.
Thank you!
Clark
Is there anyone working on XML integration?
Services include:
a) Import/Export to XML (DTD defines schema)
b) Access (through stored procedures) to XML (PSAX anyone?)
b) Emulated tables (that direct queries to XML queries)?
c) Other fun XML items.
:) Clark
On Mon, 14 Dec 1998, Clark Evans wrote:
Anyone working on Row level locking and
on-line recovery?
row level loocking shoudl be in place for v6.5...not sure about
on-line recovery, but I *believe* Jan is working on redo-log support...
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
On Mon, 14 Dec 1998, The Hermit Hacker wrote:
// row level loocking shoudl be in place for v6.5...not sure about
// on-line recovery, but I *believe* Jan is working on redo-log
// support...
Ooh, is this the kind of log you can use for transaction
replication?
--
Principle Member Technical Staff, beyond.com The world is watching America,
pub 1024/3CAE01D5 1994/11/03 Dustin Sallings <dustin@spy.net>
| Key fingerprint = 87 02 57 08 02 D0 DA D6 C8 0F 3E 65 51 98 D8 BE
L______________________________________________ and America is watching TV. __