From: | "Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org> |
---|---|
To: | Ron Johnson <ron(dot)l(dot)johnson(at)cox(dot)net> |
Cc: | PgSQL General ML <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Catalog vs. user table format (was Re: State of Beta |
Date: | 2003-09-20 22:01:58 |
Message-ID: | 20030920190027.R6867@ganymede.hub.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Sat, 20 Sep 2003, Ron Johnson wrote:
> On Sat, 2003-09-20 at 11:17, Tom Lane wrote:
> > "Marc G. Fournier" <scrappy(at)postgresql(dot)org> writes:
> > > No, I'm not suggesting no catalog changes ... wait, I might be wording
> > > this wrong ... there are two changes that right now requires a
> > > dump/reload, changes to the catalogs and changes to the data structures,
> > > no? Or are these effectively inter-related?
> >
> > Oh, what you're saying is no changes in user table format. Yeah, we
>
> Whew, we're finally on the same page!
>
> So, some definitions we can agree on?
> "catalog change": CREATE or ALTER a pg_* table.
> "on-disk structure", a.k.a. "user table format": the way that the
> tables/fields are actually stored on disk.
>
> So, a catalog change should *not* require a dump/restore, but an
> ODS/UTF change should.
As long as pg_update is updated/tested for this, yes, that is what the
thought is ... but, that still requires someone(s) to step up and work
on/maintain pg_upgrade for this to happen ... all we are agreeing to right
now is implement a policy whereby maintaining pg_upgrade is *possible*,
not one where maintaining pg_upgrade is *done* ...
From | Date | Subject | |
---|---|---|---|
Next Message | Mike Mascari | 2003-09-20 22:18:48 | Re: PG + PHP, was Re: Zend survey result about dbms... |
Previous Message | Ron Johnson | 2003-09-20 21:54:30 | Re: need for in-place upgrades |