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 enhanceme
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, ri
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 locale
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 s
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
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 compatibilit
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.
> >> bt
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 uppe
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
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
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
> occurr
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.
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
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 compi
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 cha
> 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 importa
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 t
17 matches
Mail list logo
