Tom Lane wrote: > Peter Eisentraut <[EMAIL PROTECTED]> 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
