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.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
