On Tue, Feb 21, 2006 at 10:27:15AM +0900, Tatsuo Ishii wrote:
> If you consider to allow only UTF-16 or whatever encoding in backend,
> I will strongly against the idea. We Japanese need those encodings
> native support. Converting those encodings with Unicode everytime when
> backend and forntend
> On Sat, Feb 18, 2006 at 08:16:07PM -0800, Bill Moseley wrote:
> > Is the Holy Grail encoding and lc_collate settings per column?
>
> Well yes. I've been trying to create a system where you can handle
> multiple collations in the same database. I posted the details to
> -hackers and got part of t
On Mon, Feb 20, 2006 at 05:30:06PM -0500, Greg Stark wrote:
> Martijn van Oosterhout writes:
> > By way of example, see ICU which is an internationalisation library
> > we're considering to get consistant locale support over all platforms.
> > It supports one encoding, namely UTF-16. It has variou
Martijn van Oosterhout writes:
> On Sat, Feb 18, 2006 at 08:16:07PM -0800, Bill Moseley wrote:
> > Is the Holy Grail encoding and lc_collate settings per column?
>
> By way of example, see ICU which is an internationalisation library
> we're considering to get consistant locale support over all
On Sat, Feb 18, 2006 at 08:16:07PM -0800, Bill Moseley wrote:
> Is the Holy Grail encoding and lc_collate settings per column?
Well yes. I've been trying to create a system where you can handle
multiple collations in the same database. I posted the details to
-hackers and got part of the way, but
On Sat, Feb 18, 2006 at 09:31:27PM -0500, Greg Stark wrote:
> Anything else and the collation just won't work properly. It will be
> expecting UTF-8 and be fed ISO-8859-1 strings, resulting in weird
> and sometimes inconsistent sort orders.
So if I have utf8 encoded text and the lc_collate is anyt
Bill Moseley <[EMAIL PROTECTED]> writes:
> $ LC_ALL=en_US.UTF-8 locale charmap
> UTF-8
>
> $ LC_ALL=en_US locale charmap
> ISO-8859-1
>
> $ LC_ALL=C locale charmap
> ANSI_X3.4-1968
Unfortunately Postgres only supports a single collation cluster-wide. So
depending on whi
Bill Moseley wrote:
> What's a bad idea? Having a lc_collate on the cluster that doesn't
> support the encodings in the databases?
Exactly
> Again, not sure what "it" is, but I do find it confusing when the
> cluster can have only one lc_collate, but the databases on that
> cluster can have more
On Sat, Feb 18, 2006 at 01:40:09PM -0500, Tom Lane wrote:
> Bill Moseley <[EMAIL PROTECTED]> writes:
> > - To clarify the first point, if the database is encoded utf-8 and
> > lc_collate is en_US then Postgresql does NOT try to convert utf-8 to
> > 8859-1 before sorting.
>
> Basically, this is a h
Bill Moseley <[EMAIL PROTECTED]> writes:
> - To clarify the first point, if the database is encoded utf-8 and
> lc_collate is en_US then Postgresql does NOT try to convert utf-8 to
> 8859-1 before sorting.
Basically, this is a horribly bad idea and you should never do it.
The database encoding sho
Bill Moseley wrote:
> What's the server encoding?
When you say "My database is in utf8", then "utf8" is the server
encoding.
> Does that mean if the encoding is anything other than "C"
C is a locale, not an encoding.
> Just that sorting utf8 is a bit more work that sorting raw bytes.
Sorting
On Sat, Feb 18, 2006 at 05:20:19PM +0100, Peter Eisentraut wrote:
> > 2) What client encoding is used if the client does not specify one?
>
> the server encoding
What's the server encoding? The environment when the cluster is
started? How do you find out what it's running as?
Does that mean if
Bill Moseley wrote:
> Do I have these statements correct?
yes
> 1) What else is the database's encoding used for besides to determine
> how to convert text in input and output based on the client encoding?
nothing
> 2) What client encoding is used if the client does not specify one?
the server
13 matches
Mail list logo
