1 |
> c) Upgrading between major versions of PostgreSQL requires the DB admin to |
2 |
> bump the database using the old version, moving the database away and to |
3 |
> reload the dump into a new database cluster using the new version of |
4 |
> PostgreSQL. Having to take down the old server and purging the old version |
5 |
> of PostgreSQL before being able to try out the new one is more than |
6 |
> cumbersome. Therefore a slotted postgresql-server is needed to make the |
7 |
> upgrade easier. |
8 |
|
9 |
As I read upstream's documentation¹, this is incorrect: |
10 |
|
11 |
# It is recommended that you use the pg_dump and pg_dumpall programs from the |
12 |
# newer version of PostgreSQL, to take advantage of any enhancements that may |
13 |
# have been made in these programs. Current releases of the dump programs can |
14 |
# read data from any server version back to 7.0. |
15 |
|
16 |
This has also been pointed out in a bug report, duped by some overzealous bug |
17 |
wrangler a few months ago. |
18 |
|
19 |
> What do the new ebuilds offer: |
20 |
> a) A split into dev-db/postgresql-{base,server,docs}. Now, I know that |
21 |
> splitting up packages isn't the Gentoo way. I know we could have done it |
22 |
> using USE flags but this approach gives more flexibility due to the current |
23 |
> way how binary packages are being generated and distributed. |
24 |
|
25 |
I wouldn't say so. Needlessly growing the forest of odd named, badly |
26 |
documented and sometimes needlessly added use flags is something I'm not fond |
27 |
of, looking at the development of Gentoo. |
28 |
|
29 |
|
30 |
Thanks to everyone taking care of our PostgreSQL packages. |
31 |
|
32 |
|
33 |
Carsten |
34 |
|
35 |
|
36 |
[1] http://www.postgresql.org/docs/8.2/interactive/migration.html |