Thread added to TODO.detail.
---
Greg Stark wrote:
> Tom Lane <[EMAIL PROTECTED]> writes:
>
> > Greg Stark <[EMAIL PROTECTED]> writes:
> > > I still doesn't get where the hostility towards this functionality comes
> > > fr
On Mon, Sep 05, 2005 at 01:52:45AM +0200, Petr Jelinek wrote:
> 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 thi
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
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
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
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
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
Martijn van Oosterhout writes:
> 2. Locale data needs to be combined with a charset and compiled to work
> with the library. PostgreSQL supports at least 15 charsets but we don't
> want to ship compiled versions of all of these (Debian learnt that the
> hard way). So, how do we generate the file
Tom Lane <[EMAIL PROTECTED]> writes:
> Greg Stark <[EMAIL PROTECTED]> writes:
> > I still doesn't get where the hostility towards this functionality comes
> > from.
>
> We're not really willing to say "here is a piece of syntax REQUIRED
> BY THE SQL SPEC which we only support on some platforms".
On Fri, Sep 02, 2005 at 11:42:21AM -0400, Tom Lane wrote:
> The objection is fundamentally that a platform-specific implementation
> cannot be our long-term goal, and so expending effort on creating one
> seems like a diversion. If there were a plan put forward showing how
> this is just a useful
AgentM wrote:
> The sources can be found here:
> http://darwinsource.opendarwin.org/10.4.2/Libc-391/locale/xlocale.c
>
> The Apple License *is* necessarily compatible with the BSD License.
> http://www.gnu.org/philosophy/apsl.html
Does compatibile mean our combined work is still BSD licensed?
--
The sources can be found here:
http://darwinsource.opendarwin.org/10.4.2/Libc-391/locale/xlocale.c
The Apple License *is* necessarily compatible with the BSD License.
http://www.gnu.org/philosophy/apsl.html
On Sep 2, 2005, at 11:44 AM, Tom Lane wrote:
Martijn van Oosterhout writes:
[1] http
On Fri, Sep 02, 2005 at 12:44:00PM -0400, Tom Lane wrote:
>
> Hmm, the more general page seems to be
>
> http://www.hmug.org/man/3/xlocale.php
>
> This seems to be pretty much exactly what we want, at least API-wise.
> Now, if we can find an implementation of this with a BSD license ;-) ...
Ye
Martijn van Oosterhout writes:
> [1] http://www.hmug.org/man/3/newlocale.php
Hmm, the more general page seems to be
http://www.hmug.org/man/3/xlocale.php
This seems to be pretty much exactly what we want, at least API-wise.
Now, if we can find an implementation of this with a BSD license ;-) .
On Fri, Sep 02, 2005 at 03:04:20PM +0200, Martijn van Oosterhout wrote:
> Supports any glibc platform and possibly Win32.
MacOS X [1] supports this also apparently. And for glibc it appears to
have been accepted as part of the API since 2.3.2 and formally accepted
into LSB3.0. Win32 claims to have
Greg Stark <[EMAIL PROTECTED]> writes:
> I still doesn't get where the hostility towards this functionality comes from.
We're not really willing to say "here is a piece of syntax REQUIRED
BY THE SQL SPEC which we only support on some platforms". readline,
O_DIRECT, and the like are a completely i
Martijn van Oosterhout writes:
> Supports any glibc platform and possibly Win32.
>
> Adds:
> SELECT ... ORDER BY expr COLLATE 'locale'
> CREATE INDEX locale_index ON table(expr COLLATE 'locale')
> Index scan used when COLLATE order permits
>
> This is just a proof of concept patch. I didn
Supports any glibc platform and possibly Win32.
Adds:
SELECT ... ORDER BY expr COLLATE 'locale'
CREATE INDEX locale_index ON table(expr COLLATE 'locale')
Index scan used when COLLATE order permits
This is just a proof of concept patch. I didn't send it to -patches
because as Tom pointed out
18 matches
Mail list logo
