On Mon, Jan 22, 2001 at 03:09:03PM -0800, Nathan Myers wrote:
...
> Posix systems include a set of commands for dumping locales in a standard
> format, and building from them. Instead of shipping locales and code to
> operate on them, one might include a script to run these tools (where
> the
On Mon, Jan 22, 2001 at 05:46:09PM -0500, Tom Lane wrote:
...
> Are there any BSD-license locale and/or timezone libraries that we might
> assimilate in this way? We could use an LGPL'd library if there is no
> other alternative, but I'd just as soon not open up the license issue.
The "Citrus P
> And IIRC SQL9x prescribe support for multiple locales (or at least
> multiple
> collating sequences) within one database simultaneously.
Sounds like SQL92/99 COLLATE things is the way we should go, IMHO.
--
Tatsuo Ishii
On Mon, Jan 22, 2001 at 05:46:09PM -0500, Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > Is there any possibility to use, in a portable way, only our own locale
> > definition files, without reimplementing all the sorts uppercases etc. ?
>
> The situation is not too much differe
Hannu Krosing <[EMAIL PROTECTED]> writes:
> Is there any possibility to use, in a portable way, only our own locale
> definition files, without reimplementing all the sorts uppercases etc. ?
AFAIK there is not --- the standard C library APIs do not specify how to
represent this information. Thu
Peter Eisentraut wrote:
>
> Tom Lane writes:
>
> > Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
> > > Just to understand things correctly. Is the Like optimization disabled
> > > for all non-ASCII char sets, or (imho correctly) for non charset ordered
> > > collations (LC_COLLATE) ?
> >
>
Tom Lane writes:
> Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
> > Just to understand things correctly. Is the Like optimization disabled
> > for all non-ASCII char sets, or (imho correctly) for non charset ordered
> > collations (LC_COLLATE) ?
>
> Currently it's disabled whenever LC_COLL
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
> Just to understand things correctly. Is the Like optimization disabled
> for all non-ASCII char sets, or (imho correctly) for non charset ordered
> collations (LC_COLLATE) ?
Currently it's disabled whenever LC_COLLATE is neither C nor POSIX.
> > I made a reproduceable example of things going wrong with a "en_US"
> > locale which is the widely-used (single-byte) ISO-8859-1 Latin 1 charset.
>
> en_US uses multi-pass collation rules. It's those collation rules, not
> the charset per se, that causes the problem.
Just to understand thi
[EMAIL PROTECTED] (Rob van Nieuwkerk) writes:
> But if anybody thinks that selects with LIKE on indexed columns with
> single-byte non-ASCII characters are working OK: they are not !! See my
> posting and following thread "7.0.3 reproduceable serious select error"
> from a couple of days ago.
Ye
On Sun, 21 Jan 2001 00:25:17 + (UTC), Tom Lane <[EMAIL PROTECTED]> wrote:
>Juriy Goloveshkin <[EMAIL PROTECTED]> writes:
>> Hello, I didn't know pgsql-sources close,
>> so I wrote this code just as example of idea.
>> Can somebody review and make patch for pgsql?
>
>AFAICT this only deals with
Juriy Goloveshkin <[EMAIL PROTECTED]> writes:
> Hello, I didn't know pgsql-sources close,
> so I wrote this code just as example of idea.
> Can somebody review and make patch for pgsql?
AFAICT this only deals with the issue of single-byte characters that
sort in an order different from their nume
Hello, I didn't know pgsql-sources close,
so I wrote this code just as example of idea.
Can somebody review and make patch for pgsql?
(if this idea is good, of cource).
like-optimization is working only with ASCII, but it is simple to fix.
This programm makes greater string(I tested with KOI8-R):
13 matches
Mail list logo
