On Fri, Oct 12, 2007 at 02:03:47PM +0100, Gregory Stark wrote:
This approach doesn't address that but I don't think it makes the problems
there any worse either. That is, I think already have these problems around
shared tables.
Or we could just setup encodings/locales per column and the
Peter Eisentraut [EMAIL PROTECTED] writes:
Am Freitag, 12. Oktober 2007 schrieb Gregory Stark:
. when creating a new database from a template the new locale and encoding
must be identical to the template database's encoding and locale. Unless
the template is template0 in which case we
Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Am Freitag, 12. Oktober 2007 schrieb Gregory Stark:
It would make Postgres inconsistent and less integrated with the rest of
the OS. How do you explain that Postgres doesn't follow the system's
configurations and the collations don't
Peter Eisentraut [EMAIL PROTECTED] writes:
Am Freitag, 12. Oktober 2007 schrieb Gregory Stark:
It would make Postgres inconsistent and less integrated with the rest of
the OS. How do you explain that Postgres doesn't follow the system's
configurations and the collations don't agree with the
On Fri, Oct 12, 2007 at 03:28:26PM +0100, Gregory Stark wrote:
Fix the problem by making ICU a smaller less complex dependency?
How? It's 95% data, you can't reduce that. glibc also has 10MB of locale
data. That actual code is much smaller than postgres and doesn't depend
on any other
Michael Glaesemann wrote:
On Oct 12, 2007, at 10:19 , Gregory Stark wrote:
It would make Postgres inconsistent and less integrated with the rest
of the
OS. How do you explain that Postgres doesn't follow the system's
configurations and the collations don't agree with the system
collations?
Am Freitag, 12. Oktober 2007 schrieb Martijn van Oosterhout:
Where we're stuck is that we can't agree on a
source of locale data. People don't want the ICU or glibc data and
there's no other source as readily available.
What were the objections to ICU?
--
Peter Eisentraut
Martijn van Oosterhout [EMAIL PROTECTED] writes:
People don't want the ICU or glibc data and there's no other source as
readily available.
Perhaps we should fix that problem, rather than making more
workarounds.
Fix the problem by making ICU a smaller less complex dependency?
Or fix the
Am Freitag, 12. Oktober 2007 schrieb Gregory Stark:
. when creating a new database from a template the new locale and encoding
must be identical to the template database's encoding and locale. Unless
the template is template0 in which case we rebuild all indexes after
copying.
Why would you
It seems like the root of the problems we're butting our heads against with
encoding and locale is all the same issue: it's nonsensical to take the locale
at initdb time per-cluster and then allow user-specified encoding
per-database. If anything it would make more sense to go the other way
On Oct 12, 2007, at 10:19 , Gregory Stark wrote:
It would make Postgres inconsistent and less integrated with the
rest of the
OS. How do you explain that Postgres doesn't follow the system's
configurations and the collations don't agree with the system
collations?
How is this
Peter Eisentraut [EMAIL PROTECTED] writes:
Am Freitag, 12. Oktober 2007 schrieb Martijn van Oosterhout:
Where we're stuck is that we can't agree on a
source of locale data. People don't want the ICU or glibc data and
there's no other source as readily available.
What were the objections to
Am Freitag, 12. Oktober 2007 schrieb Gregory Stark:
It would make Postgres inconsistent and less integrated with the rest of
the OS. How do you explain that Postgres doesn't follow the system's
configurations and the collations don't agree with the system collations?
We already have our own
Martijn van Oosterhout [EMAIL PROTECTED] writes:
On Fri, Oct 12, 2007 at 03:28:26PM +0100, Gregory Stark wrote:
I think realistically we're basically waiting for strcoll_l to become
standardized by POSIX so we can depend on it.
I think we could be waiting forever then.
strcoll is only a
14 matches
Mail list logo
