Re: Catalog vs. user table format (was Re: State of Beta

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

In response to

Browse pgsql-general by date

  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