Such a module can be gotten from:

ftp.duke.edu/pub/perl/modules/by-module/Pg

tom

On Fri, 04 Dec 1998, you wrote:
>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

Fri, 4 Dec 1998 14:35:51 +0000
Tom Werges <tom@citiscape.com>
Re: [GENERAL] 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


Fri, 04 Dec 1998 15:20:43 -0600
Bob Kruger <bkruger@mindspring.com>
Perl DBD / DBI modules
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?


Fri, 4 Dec 1998 23:48:43 +0100 (CET)
Kaare Rasmussen <kar@webline.dk>
6.4 ?
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. ____________


Fri, 4 Dec 1998 14:57:05 -0800 (PST)
Dustin Sallings <dustin@spy.net>
Re: [GENERAL] Perl DBD / DBI modules
> 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 19026

Fri, 4 Dec 1998 18:13:38 -0500 (EST)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [GENERAL] 6.4 ?
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?

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?


Thu, 10 Dec 1998 07:38:27 +0100 (CET)
Kaare Rasmussen <kar@webline.dk>
TODO list elements
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 


Thu, 10 Dec 1998 03:10:04 -0400 (AST)
The Hermit Hacker <scrappy@hub.org>
Re: [GENERAL] TODO list elements
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. __


Thu, 10 Dec 1998 00:21:57 -0800 (PST)
dustin sallings <dustin@spy.net>
Re: [GENERAL] TODO list elements
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

Thu, 10 Dec 1998 16:05:00 +0700
Vadim Mikheev <vadim@krs.ru>
Re: [GENERAL] TODO list elements
> 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 19026

Thu, 10 Dec 1998 12:15:00 -0500 (EST)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [GENERAL] TODO list elements

Moved 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 


Thu, 10 Dec 1998 13:39:57 -0400 (AST)
The Hermit Hacker <scrappy@hub.org>
Re: [GENERAL] TODO list elements


> -----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 elements
> 
> 
> 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.
>

What does it mean ?
LLL in 6.5 doesn't include row level locking ?

Thanks.

Hiroshi Inoue
Inoue@tpf.co.jp 

Mon, 14 Dec 1998 10:51:08 +0900
"Hiroshi Inoue" <Inoue@tpf.co.jp>
RE: [GENERAL] TODO list elements
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

Mon, 14 Dec 1998 15:03:12 +0700
Vadim Mikheev <vadim@krs.ru>
Re: [GENERAL] TODO list elements
> -----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 elements
> 
> 
> 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.
>

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

Mon, 14 Dec 1998 18:13:14 +0900
"Hiroshi Inoue" <Inoue@tpf.co.jp>
RE: [GENERAL] TODO list elements
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

Mon, 14 Dec 1998 16:21:03 +0700
Vadim Mikheev <vadim@krs.ru>
Re: [GENERAL] TODO list elements
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

Mon, 14 Dec 1998 16:46:30 +0000
Clark Evans <clark.evans@manhattanproject.com>
Row Level Locking, On-line Recovery
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

Mon, 14 Dec 1998 16:51:22 +0000
Clark Evans <clark.evans@manhattanproject.com>
XML Integration
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 


Mon, 14 Dec 1998 16:32:54 -0400 (AST)
The Hermit Hacker <scrappy@hub.org>
Re: [GENERAL] Row Level Locking, On-line Recovery
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. __


Tue, 15 Dec 1998 19:00:28 -0800 (PST)
dustin sallings <dustin@spy.net>
Re: [GENERAL] Row Level Locking, On-line Recovery