Richard Huxton napsal(a):
I think someone is looking at per-database locales for 8.4 - the issue
is more tricky than you might think because you need to worry about
system catalogue sort-order.
There is Google Soc project for implementing collation per database level. I
hope it will appear
should catch this...
C
-Original Message-
From: Craig Ringer [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 24, 2008 01:20
To: Christopher Condit
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] initdb in 8.3
Christopher Condit wrote:
I have a question related to this issue:
Now
Christopher Condit [EMAIL PROTECTED] writes:
Although, once you've built the index with varchar_pattern_ops index,
the following two (essentially equivalent) queries will run at vastly
different speeds:
select * from A where A.value like 'Nacho';
select * from A where A.value = 'Nacho';
Hi
I just recently compiled and installed 8.3.1 on a System that has UTF-8
as the default characterset in the environment. Copied the binaries, run
initdb without parameters, the usual stuff.
As you probably are all aware of, this results now in a cluster that
will only allow you to create
Tim Tassonis wrote:
Hi
I just recently compiled and installed 8.3.1 on a System that has UTF-8
as the default characterset in the environment. Copied the binaries, run
initdb without parameters, the usual stuff.
As you probably are all aware of, this results now in a cluster that
will only
Am Mittwoch, 23. April 2008 schrieb Tim Tassonis:
My question is: Why then is --locale=C not the default for initdb, as I
do regard it as a rather big annoyance that a default installation on
probably almost any modern linux distribution results in a UTF-8 only
cluster, fixable only by
Peter Eisentraut wrote:
Am Mittwoch, 23. April 2008 schrieb Tim Tassonis:
My question is: Why then is --locale=C not the default for initdb, as I
do regard it as a rather big annoyance that a default installation on
probably almost any modern linux distribution results in a UTF-8 only
cluster,
On Wed, Apr 23, 2008 at 04:35:04PM +0200, Tim Tassonis wrote:
Ok, let me put it in another way. If UTF-8 is chosen at initdb, only
UTF-8 databases can be created, if C is chosen, you can specify
different encodings (UTF-8, LATIN1 etc) for each database.
As I understood now, sorting will
Am Mittwoch, 23. April 2008 schrieb Tim Tassonis:
If specifying a characterset different from the default locale for a
database is such a bad idea, why is it possible at all?
Because Japanese users need this functionality. Aside from spectacularly
bizarre niche applications, that is really
Martijn van Oosterhout wrote:
On Wed, Apr 23, 2008 at 04:35:04PM +0200, Tim Tassonis wrote:
If specifying a characterset different from the default locale for a
database is such a bad idea, why is it possible at all?
It isn't possible, that's the point. What is possible is that client
can
On Wed, Apr 23, 2008 at 11:46:35AM +0200, Tim Tassonis wrote:
As you probably are all aware of, this results now in a cluster that
will only allow you to create UTF-8 databases. I have read some posts
regarding this topic where it is explained that allowing LATIN1 on a
cluster
Sent: Wednesday, April 23, 2008 12:22
To: Martijn van Oosterhout
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] initdb in 8.3
Martijn van Oosterhout wrote:
On Wed, Apr 23, 2008 at 04:35:04PM +0200, Tim Tassonis wrote:
If specifying a characterset different from the default locale
Karsten Hilbert wrote:
On Wed, Apr 23, 2008 at 11:46:35AM +0200, Tim Tassonis wrote:
As you probably are all aware of, this results now in a cluster that
will only allow you to create UTF-8 databases. I have read some posts
regarding this topic where it is explained that allowing LATIN1 on
Christopher Condit wrote:
I have a question related to this issue:
Now that the locale has changed, it seems that the planner no longer
wants to use the indexes for running LIKE queries on varchar columns
unless I specify varchar_pattern_ops when creating the index. And if I
create the index
14 matches
Mail list logo
