Re: WIN1252 patch broke my database

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

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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

> 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?

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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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

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/

Peter Eisentraut <peter_e(at)gmx(dot)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

Tom Lane wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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

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/

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Am Donnerstag, 17. Mrz 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.

As long as client code only uses the names, I suppose we are OK. I'm a
bit worried about that assumption though, since it's not like the
numbers aren't exposed to view in pg_database and pg_conversion ...

regards, tom lane