Thread: WIN1250 as server encoding

Some people have requested to add WIN1250 as an allowed server encoding.  
So far, the order of the encoding numbers determined which ones were 
client-only, so in order not to renumber the encodings, I could only 
come up with the attached ugly solution.  If no one thinks of a better 
one, we'll go with that.

It would also be good if someone who has an environment that calls for 
WIN1250 (that is, Windows and an appropriate language environment) 
could test whether this actually does anything besides compiling 
without errors. :)

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

On Wed, Sep 15, 2004 at 05:02:44PM +0200, Peter Eisentraut wrote:
> Some people have requested to add WIN1250 as an allowed server encoding.  
> So far, the order of the encoding numbers determined which ones were 
> client-only, so in order not to renumber the encodings, I could only 
> come up with the attached ugly solution.  If no one thinks of a better 
> one, we'll go with that.
Probably a silly suggestion, but...  A second encoding number which happens
to assign the same character codes as WIN1250, with a 1-to-1 translation
table, and renaming the old number to make room for the new one in newly
compiled code?


Jeroen

Peter Eisentraut <peter_e@gmx.net> writes:
> Some people have requested to add WIN1250 as an allowed server encoding.  
> So far, the order of the encoding numbers determined which ones were 
> client-only, so in order not to renumber the encodings, I could only 
> come up with the attached ugly solution.  If no one thinks of a better 
> one, we'll go with that.

Can't we just renumber them?

AFAIR, the only place where these numbers are stored is in
pg_database.datencoding, so only the server-encoding values are frozen
in any meaningful sense.  You could rearrange the numbers currently
assigned to client encodings to preserve the range property.
        regards, tom lane

Tom Lane wrote:
> AFAIR, the only place where these numbers are stored is in
> pg_database.datencoding, so only the server-encoding values are
> frozen in any meaningful sense.  You could rearrange the numbers
> currently assigned to client encodings to preserve the range
> property.

Interesting.  I guess I was too traumatized by the last numbering change 
to ignore that possibility.  Does anyone else see a problem with that?

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