> > Tom's suggestion does not sound reasonable to me. If PostgreSQL is not
> > built with MULTIBYTE, then it means there would be no such idea
> > "encoding" in PostgreSQL becuase there is no program to handle
> > encodings. Thus it would be meaningless to assign an "encoding" to a
> > database i
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
>> Tom also mentioned that it might be possible for the server to support
>> setting the character set for a database even when multibyte wasn't
>> enabled. That would then allow clients like jdbc to get a value from
>> non-multibyte enabled servers tha
> > Still I don't see what you are wanting in the JDBC driver if
> > PostgreSQL would return "UNKNOWN" indicating that the backend is not
> > compiled with MULTIBYTE. Do you want exact the same behavior as prior
> > 7.1 driver? i.e. reading data from the PostgreSQL backend, assume its
> > encoding
> >>> Thus I would be happy if getdatabaseencoding() returned 'UNKNOWN' or
> >>> something similar when in fact it doesn't know what the encoding is
> >>> (i.e. when not compiled with multibyte).
> >>
> >
> > Is that ok for Java? I thought Java needs to know the encoding
> > beforehand so that
[ thread renamed and cross-posted to pghackers, since this isn't only
about JDBC anymore ]
Barry Lind <[EMAIL PROTECTED]> writes:
> The basic issue I have it that the server is providing an API to the
> client to get the character encoding for the database and that API can
> report incorrect in
