Thread: 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
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
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 19026
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?
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 19026
> -----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
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 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
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
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
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
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. __