Thread: 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@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
> 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 -2Implement max() and min() aggregates for array types.Patch from KojuIijima, 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, Pennsylvania19073
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@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
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, Pennsylvania19073
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
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@gmx.net> writes:
> 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.
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