You can't just randomly rearrange the pg_enc enum without forcing an
initdb, because the numeric values of the encodings appear in system
catalogs (eg pg_conversion).

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)

Tom Lane wrote:
> You can't just randomly rearrange the pg_enc enum without forcing an
> initdb, because the numeric values of the encodings appear in system
> catalogs (eg pg_conversion).

Oh, those numbers appear in the catalogs? I didn't relealize that.

I will force an initdb.

--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

> Tom Lane wrote:
>> You can't just randomly rearrange the pg_enc enum without forcing an
>> initdb, because the numeric values of the encodings appear in system
>> catalogs (eg pg_conversion).
>
> Oh, those numbers appear in the catalogs? I didn't relealize that.
>
> I will force an initdb.
>
Doesn't that also force the end-user to initdb with an upgrade?

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

Mark Woodward wrote:
> > Tom Lane wrote:
> >> You can't just randomly rearrange the pg_enc enum without forcing an
> >> initdb, because the numeric values of the encodings appear in system
> >> catalogs (eg pg_conversion).
> >
> > Oh, those numbers appear in the catalogs? I didn't relealize that.
> >
> > I will force an initdb.
> >
> Doesn't that also force the end-user to initdb with an upgrade?

Yes, 8.1 will require a dump/reload for upgrade. I think we decided
that was going to be necessary.

That has aleady happened for 8.1:

date: 2005/02/28 03:45:21; author: neilc; state: Exp; lines: +2 -2
Implement max() and min() aggregates for array types. Patch from Koju
Iijima, reviewed by Neil Conway. Catalog version number bumped,
regression tests updated.

--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Bruce Momjian wrote:
> Yes, 8.1 will require a dump/reload for upgrade. I think we decided
> that was going to be necessary.
>
> That has aleady happened for 8.1:
>
> date: 2005/02/28 03:45:21; author: neilc; state: Exp; lines: +2 -2
> Implement max() and min() aggregates for array types. Patch from Koju
> Iijima, reviewed by Neil Conway. Catalog version number bumped,
> regression tests updated.

Yes, as well as 4 other patches that have bumped the catversion number.
I think we are well past the point at which an 8.1 without an initdb
would be a plausible option (barring the materialization of a working
pg_upgrade tool, of course).

-Neil


---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

Bruce Momjian wrote:
> Tom Lane wrote:
> > You can't just randomly rearrange the pg_enc enum without forcing
> > an initdb, because the numeric values of the encodings appear in
> > system catalogs (eg pg_conversion).
>
> Oh, those numbers appear in the catalogs? I didn't relealize that.
>
> I will force an initdb.

You shouldn't insert encodings in the middle, because those numbers are
exposed to clients. We've had troubles with that before. If you add
an encoding, append it as the last one (before the client encodings in
this case). This would probably also eliminate the need for the
initdb.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Peter Eisentraut <peter_e@gmx.net> writes:
> You shouldn't insert encodings in the middle, because those numbers are
> exposed to clients. We've had troubles with that before. If you add
> an encoding, append it as the last one (before the client encodings in
> this case). This would probably also eliminate the need for the
> initdb.

It doesn't eliminate the need for initdb, because pg_conversion contains
instances of the client-only encoding numbers. I think that clients
know the client-only encoding numbers too, so I'm not sure we aren't
stuck with a compatibility issue.

Perhaps, as long as we are forced to renumber, we should reassign the
client-only encodings to higher numbers (starting at 100, perhaps)
so that there will be daylight to avoid this issue in the future.
This would cost some wasted space in the tables, I think, but that
could be worked around if it's large enough to be annoying.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
> > You shouldn't insert encodings in the middle, because those numbers are
> > exposed to clients. We've had troubles with that before. If you add
> > an encoding, append it as the last one (before the client encodings in
> > this case). This would probably also eliminate the need for the
> > initdb.
>
> It doesn't eliminate the need for initdb, because pg_conversion contains
> instances of the client-only encoding numbers. I think that clients
> know the client-only encoding numbers too, so I'm not sure we aren't
> stuck with a compatibility issue.
>
> Perhaps, as long as we are forced to renumber, we should reassign the
> client-only encodings to higher numbers (starting at 100, perhaps)
> so that there will be daylight to avoid this issue in the future.
> This would cost some wasted space in the tables, I think, but that
> could be worked around if it's large enough to be annoying.

What should I do with the CVS code now? Why is adding a gap between
client/server and client-only encodings in pg_wchar.h going to waste
space?

--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Bruce Momjian <pgman@candle.pha.pa.us> writes:
> What should I do with the CVS code now? Why is adding a gap between
> client/server and client-only encodings in pg_wchar.h going to waste
> space?

IIRC there are some tables that are indexed directly by the encoding
number, so leaving holes in the code assignments requires empty slots in
the tables (or breaking the tables into two parts, which might be easier
to maintain anyway).

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

Am Donnerstag, 17. März 2005 19:23 schrieb Tom Lane:
> It doesn't eliminate the need for initdb, because pg_conversion contains
> instances of the client-only encoding numbers. I think that clients
> know the client-only encoding numbers too, so I'm not sure we aren't
> stuck with a compatibility issue.

I think the problem case was old pg_dump versions saving the encoding number
rather than name. I don't recall any problems with renumbering the client
encodings. I believe that we in fact did that in 8.0.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/


---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend