[Charset iso-8859-1 unsupported, filtering to ASCII...]
> Hi,
>
> > > The 3 greatest technical/engineering challenges: 1) system
> > > reliability & recoverability, 2) system reliability & recoverability,
> > > and 3) system reliability and recoverability.
> >
> > And we don't have a problem in this area, do we?
>
> At the moment, not realy, but a few things would be VERY nice:
> - No need for a complete dump/restore on an major upgrade
pg_upgrade allows us to do that _when_ we don't change the on-disk
format of the data. We did not do that in 6.4, but did do that in 6.5.
I think 7.0 also will have a change. Not much we can do about that.
When we stop adding major features, pg_upgrade can be used for every
release. :-)
> - A pg_dump that ALWAYS can make a dump that can be restored without editing
> it first
> (When a user had the access to create databases, creates some, and that
> access is removed, the dump can't be restored anymore because it creates the
> user without the rights to create databases, but somewhat later tries to
> create a database with that user. I hope you understand this... :) I now
> create all databases by hand as the superuser, and set the datdba myself.
We are working on dumping in OID order. That should solve that problem.
We only came up with that solution recently.
> - A dump program that can dump/restore large objects.
>
> Don't get me wrong. I'm not complaining, and we work with PostgreSQL a lot
> without any big problems. Just some ideas to make it easier for the
> administrator.
We are going to do very long tuples in 7.0 and 7.1. This may make large
objects obsolete.
>
> And of course, thanks for all the work on PostgreSQL that makes it what it
> is now, and a Merry Cristmas!
Oh, yes, Merry Christmas to everyone too.
--
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
