Re: RPMS for 7.3 beta.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Lamar Owen <lamar(dot)owen(at)wgcr(dot)org>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: RPMS for 7.3 beta.
Date: 2002-09-17 20:40:53
Message-ID: 2595.1032295253@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Lamar Owen <lamar(dot)owen(at)wgcr(dot)org> writes:
> ... What I am looking
> at is whether the user will have to run 7.3's pg_dump in order to migrate
> older data.

AFAIK this is not *necessary*, though it may be *helpful*. Aside from
the OPAQUE issue, which we will fix one way or another, I am aware of
these issues for loading a pre-7.3 dump:

* A reloaded dump will fail to GRANT EXECUTE TO PUBLIC on functions,
likewise fail to GRANT USAGE TO PUBLIC on procedural languages.
This may not bother some people, but for those it does bother,
it's not that hard to issue the GRANTs manually after loading the dump.

* A reloaded dump will not create dependencies between serial columns
and sequence objects, nor between triggers and foreign key
constraints, thus 7.3's nifty new support for DROP CONSTRAINT won't
work, nor will dropping a table make its associated sequences go away.
However, this can be boiled down to saying that it still works like it
did before.

There are of course the same old same old issues regarding pg_dump's
ability to choose a good dump order, but these are not worse than before
either, and would bite you just as badly if you tried to reload your
dump into 7.2.*.

Using 7.3's pg_dump would help you with the GRANT issue, but AFAIR it
won't do anything for reconstructing serial or foreign-key dependencies.
And it definitely wouldn't help on the ordering issue. So it's probably
not worth the trouble if you can't do it trivially, which you can't in
an RPM-upgrade context. (We do advise it for people who are building
from source, since it's not difficult for them.)

In short, I'm not sure why you and Oliver are so unhappy. We may not
have made the world better than before for upgrade scenarios, but I
don't think we've made it worse either.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message scott.marlowe 2002-09-17 20:44:54 a quick question
Previous Message Bruce Momjian 2002-09-17 20:18:04 Old pgsql versions