Horton

Thread

  1. Re: [GENERAL] Perl DBD / DBI modules

    Tom Werges <tom@citiscape.com> — 1998-12-04T14:35:51Z

    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

  2. Perl DBD / DBI modules

    Bob Kruger <bkruger@mindspring.com> — 1998-12-04T21:20:43Z

    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

  3. 6.4 ?

    Kaare Rasmussen <kar@webline.dk> — 1998-12-04T22:48:43Z

    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?

  4. Re: [GENERAL] Perl DBD / DBI modules

    Dustin Sallings <dustin@spy.net> — 1998-12-04T22:57:05Z

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

  5. Re: [GENERAL] 6.4 ?

    Bruce Momjian <maillist@candle.pha.pa.us> — 1998-12-04T23:13:38Z

    > 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

  6. TODO list elements

    Kaare Rasmussen <kar@webline.dk> — 1998-12-10T06:38:27Z

    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?

  7. Re: [GENERAL] TODO list elements

    Marc G. Fournier <scrappy@hub.org> — 1998-12-10T07:10:04Z

    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

  8. Re: [GENERAL] TODO list elements

    Dustin Sallings <dustin@spy.net> — 1998-12-10T08:21:57Z

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

  9. Re: [GENERAL] TODO list elements

    Vadim Mikheev <vadim@krs.ru> — 1998-12-10T09:05:00Z

    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

  10. Re: [GENERAL] TODO list elements

    Bruce Momjian <maillist@candle.pha.pa.us> — 1998-12-10T17:15:00Z

    > 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

  11. Re: [GENERAL] TODO list elements

    Marc G. Fournier <scrappy@hub.org> — 1998-12-10T17:39:57Z

    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

  12. RE: [GENERAL] TODO list elements

    Hiroshi Inoue <inoue@tpf.co.jp> — 1998-12-14T01:51:08Z

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

  13. Re: [GENERAL] TODO list elements

    Vadim Mikheev <vadim@krs.ru> — 1998-12-14T08:03:12Z

    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

  14. RE: [GENERAL] TODO list elements

    Hiroshi Inoue <inoue@tpf.co.jp> — 1998-12-14T09:13:14Z

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

  15. Re: [GENERAL] TODO list elements

    Vadim Mikheev <vadim@krs.ru> — 1998-12-14T09:21:03Z

    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

  16. Row Level Locking, On-line Recovery

    Clark C. Evans <clark.evans@manhattanproject.com> — 1998-12-14T16:46:30Z

    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

  17. XML Integration

    Clark C. Evans <clark.evans@manhattanproject.com> — 1998-12-14T16:51:22Z

    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

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

    Marc G. Fournier <scrappy@hub.org> — 1998-12-14T20:32:54Z

    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

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

    Dustin Sallings <dustin@spy.net> — 1998-12-16T03:00:28Z

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