On 4/19/15 7:46 AM, Palle Girgensohn wrote:
Just poking this old thread again. What happened here, is anyone putting work
into this area at the moment?
I plan to look at it for 9.6.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
27 nov 2014 kl. 16:03 skrev Tom Lane t...@sss.pgh.pa.us:
Another issue is that (AFAIK) ICU doesn't support any non-Unicode
encodings, which means that a build supporting *only* ICU collations is a
nonstarter IMO.
The patch I originally wrote replaces strwcoll but for keeps the original
Am 26.11.2014 um 17:46 schrieb Geoff Montee geoff.mon...@gmail.com:
This topic reminds me of a thread from a couple months ago:
http://www.postgresql.org/message-id/f8268db6-b50f-429f-8289-da8ffa5f2...@tripadvisor.com
It sounds like adding ICU support to core may also allow for adding
On Thu, Nov 27, 2014 at 9:09 AM, Jakob Egger ja...@eggerapps.at wrote:
Am 26.11.2014 um 17:46 schrieb Geoff Montee geoff.mon...@gmail.com:
This topic reminds me of a thread from a couple months ago:
http://www.postgresql.org/message-id/f8268db6-b50f-429f-8289-da8ffa5f2...@tripadvisor.com
On 27 Nov 2014 09:09, Jakob Egger ja...@eggerapps.at wrote:
ICU offers a lot more collations than the OS. For example, besides
de_CH it also offers de_CH@collation=phonebook. Adding support for
these is a bit more involved.
* initdb would need to be extended to also look for collations offered
Greg Stark st...@mit.edu writes:
Hm. Actually the pg_collation catalog might give a handy way out for the
issue of being inconsistent with the system collation. We could support
both sets of collations and let the user select an ICU collation or system
collation at runtime.
+1 ... this seems
On Thu, Nov 27, 2014 at 7:03 AM, Tom Lane t...@sss.pgh.pa.us wrote:
+1 ... this seems like a nice end-run around the backwards compatibility
problem.
Another issue is that (AFAIK) ICU doesn't support any non-Unicode
encodings, which means that a build supporting *only* ICU collations is a
Another issue is that (AFAIK) ICU doesn't support any non-Unicode
encodings, which means that a build supporting *only* ICU collations is a
nonstarter IMO. So we really need a way to deal with both system and ICU
collations, and treating the latter as a separate subset of pg_collation
seems
Hi Palle,
thanks for the extremely quick response!
In that case I will include the patch in Postgres.app. Missing support for
per-column collations is preferable to missing support for the standard locale!
I'll have a look at the per-column collation support, it would be great if
PostgreSQL
On Wed, Nov 26, 2014 at 8:41 AM, Palle Girgensohn gir...@pingpong.net wrote:
Hi!
This is indeed a very well tested patch as we've run it in production for 8+
years on 20+ systems.
It is not included upstreams mainly because I did ask for it to happen. I've
been aiming to do it but haven't
26 nov 2014 kl. 09:58 skrev Magnus Hagander mag...@hagander.net:
On Wed, Nov 26, 2014 at 8:41 AM, Palle Girgensohn gir...@pingpong.net wrote:
Hi!
This is indeed a very well tested patch as we've run it in production for 8+
years on 20+ systems.
It is not included upstreams mainly
One of the
big arguments against bringing it in then (because it worked) was that
we'd bring in another compile time dependency that's actually larger
than PostgreSQL itself.
Magnus: I don't see how this is a problem as long as using ICU is *optional*.
On systems with a working strcoll there
26 nov 2014 kl. 10:36 skrev Jakob Egger ja...@eggerapps.at:
One of the
big arguments against bringing it in then (because it worked) was that
we'd bring in another compile time dependency that's actually larger
than PostgreSQL itself.
Magnus: I don't see how this is a problem as long as
Bear in mind that this might alter the way indexes are built. From the top of
my head, I just can't remember if this is true or not. I'm probably wrong?
Magnus? You would have to try.
That's why I want to include it in the first version of 9.4, when people need
to dump reload their
26 nov 2014 kl. 10:48 skrev Jakob Egger ja...@eggerapps.at:
Bear in mind that this might alter the way indexes are built. From the top
of my head, I just can't remember if this is true or not. I'm probably
wrong? Magnus? You would have to try.
That's why I want to include it in the
On Wed, Nov 26, 2014 at 9:48 AM, Jakob Egger ja...@eggerapps.at wrote:
Bear in mind that this might alter the way indexes are built. From the top
of my head, I just can't remember if this is true or not. I'm probably
wrong? Magnus? You would have to try.
That's why I want to include it in
Am 26.11.2014 um 11:05 schrieb Dave Page dp...@postgresql.org:
You may want to bear in mind that postgres.app is on the main PG
downloads page on the website. If you're patching Postgres to add a
feature like this, it would become a fork and would have to be moved
out of the PostgreSQL Core
On Wed, Nov 26, 2014 at 10:13 AM, Jakob Egger ja...@eggerapps.at wrote:
Am 26.11.2014 um 11:05 schrieb Dave Page dp...@postgresql.org:
You may want to bear in mind that postgres.app is on the main PG
downloads page on the website. If you're patching Postgres to add a
feature like this, it
On Wed, Nov 26, 2014 at 11:13 AM, Jakob Egger ja...@eggerapps.at wrote:
Am 26.11.2014 um 11:05 schrieb Dave Page dp...@postgresql.org:
You may want to bear in mind that postgres.app is on the main PG
downloads page on the website. If you're patching Postgres to add a
feature like this, it
Am 26.11.2014 um 11:20 schrieb Dave Page dp...@postgresql.org:
On Wed, Nov 26, 2014 at 10:13 AM, Jakob Egger ja...@eggerapps.at wrote:
Am 26.11.2014 um 11:05 schrieb Dave Page dp...@postgresql.org:
You may want to bear in mind that postgres.app is on the main PG
downloads page on the
Is it broken *worse* in 9.4 than it was in previous versions?
No.
Because the indices need to be rebuilt, the only realistic opportunity for
applying this patch to Postgres.app is when releasing a major new version,
since then people need to migrate their data anyway. That's why I wanted to
2014-11-26 9:58 GMT+01:00 Magnus Hagander mag...@hagander.net:
On Wed, Nov 26, 2014 at 8:41 AM, Palle Girgensohn gir...@pingpong.net
wrote:
Hi!
This is indeed a very well tested patch as we've run it in production
for 8+
years on 20+ systems.
It is not included upstreams mainly
26 nov 2014 kl. 11:44 skrev Jakob Egger ja...@eggerapps.at:
Am 26.11.2014 um 11:20 schrieb Dave Page dp...@postgresql.org:
On Wed, Nov 26, 2014 at 10:13 AM, Jakob Egger ja...@eggerapps.at wrote:
Am 26.11.2014 um 11:05 schrieb Dave Page dp...@postgresql.org:
You may want to bear in
I find it hard to believe the original premise of this thread. We knew
there were some problems with OSX and FreeBSD but surely they can't be
completely broken? What happens if you run ls with your locale set
to something like fr_FR.UTF8 ? Does Apple not sell Macs in countries
other than the US?
On Nov 26, 2014, at 8:21 AM, Greg Stark st...@mit.edu wrote:
I find it hard to believe the original premise of this thread. We knew
there were some problems with OSX and FreeBSD but surely they can't be
completely broken?
Ever tried to use Spotlight for searching (English) on the Mac, not
26 nov 2014 kl. 15:21 skrev Greg Stark st...@mit.edu:
I find it hard to believe the original premise of this thread. We knew
there were some problems with OSX and FreeBSD but surely they can't be
completely broken? What happens if you run ls with your locale set
to something like
26 nov 2014 kl. 15:56 skrev Neil Tiffin ne...@neiltiffin.com:
On Nov 26, 2014, at 8:21 AM, Greg Stark st...@mit.edu wrote:
I find it hard to believe the original premise of this thread. We knew
there were some problems with OSX and FreeBSD but surely they can't be
completely broken?
26 nov 2014 kl. 14:06 skrev Palle Girgensohn gir...@pingpong.net:
Well, this discussion actually pushes the priority quite a bit for me --
someone else actually beeing interested about the patch... I thought it was
just me... :)=
By pushes the priority, I mean it gets more prioritized,
On Wed, Nov 26, 2014 at 10:17 AM, Palle Girgensohn gir...@pingpong.net wrote:
26 nov 2014 kl. 14:06 skrev Palle Girgensohn gir...@pingpong.net:
Well, this discussion actually pushes the priority quite a bit for me --
someone else actually beeing interested about the patch... I thought
On Wed, Nov 26, 2014 at 6:21 AM, Greg Stark st...@mit.edu wrote:
There were a number of problems with using ICU including the large
dependency and the limitations of the iterator model but the main
issue was that it's fundamentally a choice between being consistent
with every other application
On Wed, Nov 26, 2014 at 2:05 AM, Dave Page dp...@postgresql.org wrote:
You may want to bear in mind that postgres.app is on the main PG
downloads page on the website. If you're patching Postgres to add a
feature like this, it would become a fork and would have to be moved
out of the PostgreSQL
On 11/26/14 12:46 PM, Peter Geoghegan wrote:
On Wed, Nov 26, 2014 at 2:05 AM, Dave Page dp...@postgresql.org wrote:
You may want to bear in mind that postgres.app is on the main PG
downloads page on the website. If you're patching Postgres to add a
feature like this, it would become a fork and
26 nov 2014 kl. 20:42 skrev Peter Eisentraut pete...@gmx.net:
(A build
option and a more explicit warning might be nice.)
In the freebsd ports, it is an option, default is off. :-)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On 11/26/14 3:42 PM, Palle Girgensohn wrote:
26 nov 2014 kl. 20:42 skrev Peter Eisentraut pete...@gmx.net:
(A build
option and a more explicit warning might be nice.)
In the freebsd ports, it is an option, default is off. :-)
That's even better.
Sorry, I looked at the port sources and
Hi!
This is indeed a very well tested patch as we've run it in production for 8+
years on 20+ systems.
It is not included upstreams mainly because I did ask for it to happen. I've
been aiming to do it but haven't got around to it. Also, since 9.2 (?) there is
support in PostgreSQL for
35 matches
Mail list logo
