On Sat, Sep 03, 2005 at 05:44:50PM -0400, Greg Stark wrote:
[...] Nor is it
simpler for sysadmins to have to maintain an entirely separate set of locales
independently from the system locales.
Indeed, I was already coming up with mechanisms to determine what
locales the system uses and try to
3. Compiled locale files are large. One UTF-8 locale datafile can
exceed a megabyte. Do we want the option of disabling it for small
systems?
To avoid the problem, you could dynmically load the compiled
tables. The charset conversion tables are handled similar way.
Also I think it's important
On Sun, Sep 04, 2005 at 10:25:36PM +0900, Tatsuo Ishii wrote:
3. Compiled locale files are large. One UTF-8 locale datafile can
exceed a megabyte. Do we want the option of disabling it for small
systems?
To avoid the problem, you could dynmically load the compiled
tables. The charset
Magnus Hagander wrote:
Building with the VC compiler using GNU makefiles is a whole
different story - if that can be made to work reasonably easily it
would be a worthwhile goal
The main problem is that the VC compiler uses completely different
command-line options than a typical Unix
Martijn van Oosterhout wrote:
This is just a proof of concept patch. I didn't send it to -patches
because as Tom pointed out, there's no hope of it getting in due to
platform dependant behaviour.
I think it would be best if we defined an internal API for plugging in
various kinds of locale
Tatsuo Ishii [EMAIL PROTECTED] writes:
To be honest, I don't understand why we have to rely on (often broken)
system locales. I don't think building our own locale data is too
hard, and once we make up it, the maintenace cost will be very small
since it should not be changed regularly.
On R, 2005-09-02 at 11:03 -0400, Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
I wonder why we don't support more operators on Xid, so these things are
avoided? Right now we only have =, AFAIR.
I once started to make a btree opclass for XID, and stopped when it
occurred to me
Greg Stark [EMAIL PROTECTED] writes:
But there's nothing wrong with saying it's slow because your
libc is slow. Compile with this freely available library which has a better
implementation.
The hole in that argument is the assumption that there *is* a freely
available library that can be used
Hannu Krosing [EMAIL PROTECTED] writes:
On R, 2005-09-02 at 11:03 -0400, Tom Lane wrote:
I once started to make a btree opclass for XID, and stopped when it
occurred to me that XID comparison doesn't obey the transitive law.
btree won't like that...
Does this mean that Slony's usage of btree
On Sun, Sep 04, 2005 at 06:21:51PM -0400, Tom Lane wrote:
XID comparison works OK as long as you make sure that all the XIDs
extant in the system at any one time are within +/- 2 billion of each
other, and so transitivity does hold within that subset. The problem
with a btree is that
On P, 2005-09-04 at 18:21 -0400, Tom Lane wrote:
Hannu Krosing [EMAIL PROTECTED] writes:
On R, 2005-09-02 at 11:03 -0400, Tom Lane wrote:
I once started to make a btree opclass for XID, and stopped when it
occurred to me that XID comparison doesn't obey the transitive law.
btree won't
Peter Eisentraut [EMAIL PROTECTED] writes:
I think it would be best if we defined an internal API for plugging in
various kinds of locale support.
Agreed ...
Then you can hook in this
newlocale, the Windows variant, ICU, or plain-old POSIX locale
support for backward compatibility.
If
Greg Stark [EMAIL PROTECTED] writes:
I think it's sheer madness to try to reproduce large swaths of the OS
inside Postgres because you're unhappy with the quality of the OS
implementation. You should be asking yourself why OS vendors have such
a hard time getting this stuff right
In the case
Alvaro Herrera [EMAIL PROTECTED] writes:
On Sun, Sep 04, 2005 at 06:21:51PM -0400, Tom Lane wrote:
XID comparison works OK as long as you make sure that all the XIDs
extant in the system at any one time are within +/- 2 billion of each
other, and so transitivity does hold within that subset.
Tom Lane wrote:
The hole in that argument is the assumption that there *is* a freely
available library that can be used (where freely == BSD license).
We wouldn't be having this discussion if we knew of one.
I see this discussion as another reason to use ICU, I mean complete
rewrite of
Please excuse any stupidity, as although I've used postgres for quite some time, this is my first foray into developing for it. I'm working on converting the geometry stuff in adt to support 4 dimensions. For my own use, I plan on patching 8.0.3 with the files I edited in the 8.1beta source,
On Sun, 2005-09-04 at 21:45 -0700, Paul Ramsey wrote:
Chris,
PostGIS already has 4d geometry, though few functions that work with
that fourth dimension (how far is 8am, in Paris from 4pm in
London?). Have you checked if there is some room to meet your needs
with some PostGIS
17 matches
Mail list logo
