Thread: Perl DBD / DBI modules

Perl DBD / DBI modules

From
Bob Kruger
Date:
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


Re: [GENERAL] Perl DBD / DBI modules

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

6.4 ?

From
Kaare Rasmussen
Date:
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?


Re: [GENERAL] Perl DBD / DBI modules

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


Re: [GENERAL] 6.4 ?

From
Bruce Momjian
Date:
> 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

TODO list elements

From
Kaare Rasmussen
Date:
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?


Re: [GENERAL] TODO list elements

From
The Hermit Hacker
Date:
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


Re: [GENERAL] TODO list elements

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


Re: [GENERAL] TODO list elements

From
Vadim Mikheev
Date:
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

Re: [GENERAL] TODO list elements

From
Bruce Momjian
Date:
> 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

RE: [GENERAL] TODO list elements

From
"Hiroshi Inoue"
Date:

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

Re: [GENERAL] TODO list elements

From
Vadim Mikheev
Date:
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

RE: [GENERAL] TODO list elements

From
"Hiroshi Inoue"
Date:
> -----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

Re: [GENERAL] TODO list elements

From
Vadim Mikheev
Date:
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

XML Integration

From
Clark Evans
Date:
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

Row Level Locking, On-line Recovery

From
Clark Evans
Date:
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

Re: [GENERAL] Row Level Locking, On-line Recovery

From
The Hermit Hacker
Date:
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


Re: [GENERAL] Row Level Locking, On-line Recovery

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