> > My Linux box does not have *.utf8 locales at all. Probably not so many
> > platforms have them up to now, I guess.
>
> What linux do you use ?
Kind of variant of RH6.2.
> At least newer Redhat Linuxen have them and I suspect that all newer
> glibc's are capable of using them.
I guess many
I am facing an interesting core dump:
action=# select version();
version
-
PostgreSQL 7.2 on i586-pc-linux-gnu, compiled by GCC 2.95.3
(1 row)
When computing the distance between a point and a box everything
Le Mardi 14 Mai 2002 03:29, Tatsuo Ishii a écrit :
> For example, user
> might want to have a table like this in a UTF-8 database:
>
> create table t1(
>english text,-- English message
>germany text,-- Germany message
>japanese text-- Japanese message
> );
Or j
On Tue, 2002-05-14 at 03:29, Tatsuo Ishii wrote:
> > I think it is really not hard to do this for UTF-8. I don't have to know the
> > relation between the locale and the encoding. Look at this:
> > We can use the LC_CTYPE from pg_controldata or alternatively the LC_CTYPE
> > at server startup. For
> > Are you sure that say, de_DE.utf8 locale produce meaningful results
> > for any other languages?
>
> there are often subtle differences, but upper() and lower() are much
> more likely to produce right results than collation order or date/money
> formats.
>
> in fact seem to be only 10 distin
On Tue, 2002-05-14 at 09:52, Tatsuo Ishii wrote:
>
> Are you sure that say, de_DE.utf8 locale produce meaningful results
> for any other languages?
there are often subtle differences, but upper() and lower() are much
more likely to produce right results than collation order or date/money
formats
Ewald Geschwinde <[EMAIL PROTECTED]> writes:
> When using the field koord instead of a static box the system will core
> dump:
Hmm, I get garbage answers for the second and later rows, rather than
a core dump.
> Does anybody have an idea why the problem occurs?
I think the guilty party is the p
I said:
> I think the guilty party is the pfree() in dist_pb.
Indeed, removing the pfree call at line 2254 (in 7.2 sources) of
src/backend/utils/adt/geo_ops.c makes the problem go away.
I am working on a more extensive patch in hopes of fixing possible
similar errors elsewhere in this file, but
