On Sep 04 02:35, Tom Lane wrote:
> "Devrim GUNDUZ" <[EMAIL PROTECTED]> writes:
> > Like the bug report that was submitted a few days ago,
> > http://archives.postgresql.org/pgsql-bugs/2005-09/msg00233.php
> > I have the same thing for Turkish locale.
>
> Would you confirm that this is fixed by my
On Jun 15 09:33, Tom Lane wrote:
> Volkan YAZICI <[EMAIL PROTECTED]> writes:
> > Also, if you'd wish, I can prepare an ad-hoc regression tests patch
> > for LATIN5 and UTF-8 support of Turkish characters.
>
> We know it's broken. What's needed is a p
On Jun 14 05:00, Bruce Momjian wrote:
> Did we make any progress on this? If so, I can't find it.
I've made some tests for upper(), lower(), ILIKE and ~* using cvs tip.
Below are the details:
Cluster Locale | client_encoding | upper() | lower() | ILIKE | ~*
-+-+
On May 27 11:50, Tom Lane wrote:
> Volkan YAZICI <[EMAIL PROTECTED]> writes:
> > ISTM, there's a problem in the correlation of random() to outer JOINs.
>
> The random() functions are being evaluated more than once because the
> subselect gets "flattened"
Hi,
ISTM, there's a problem in the correlation of random() to outer JOINs.
Here's a test case:
BEGIN;
CREATE TEMP TABLE nuc_codes (id serial, code char(1));
COPY nuc_codes (code) FROM stdin;
A
C
D
G
H
K
M
N
R
S
T
U
V
W
X
Y
\.
SELECT id, code FROM nuc_codes;
SELECT T1.r1, T1.r2, T2.code, T3.co
On Apr 21 05:29, Balázs Klein wrote:
> Description:case insensitive match for unicode doesn't work
Case conversion of multibyte characters related bugs has been resolved
in cvs tip and will be available for 8.2.
> I raised this issue on pgsql.general -
> http://groups.google.com/group/pg
On Apr 14 06:30, wangshj wrote:
> In my database,the type oid of testdomainoid is 16385. But PQftype return 23
> for testdomainoid's type oid.
PQftype() returns the OID of the actual _type_ used in the domain.
Therefore, you get 23, OID of the int4/int type, in the above query.
> How could I get
Hi,
On Mar 09 02:00, Yury Don wrote:
> Looks like string comparison operators ignore spaces isnside of string.
> Because of this sorting on text fields is wrong.
>
> mdb=# select 'a z'::text>'ad'::text;
> ?column?
> --
> t
PostgreSQL relies on your locale for collation. Therefore, firs
On Feb 13 04:01, Andrew Klosterman wrote:
> I threw in a pthread mutex around the code making the database connections
> for each of my threads. The problem is still there ("corrupted
> double-linked list").
> ...
> Program received signal SIGILL, Illegal instruction.
> [Switching to Thread 16384
On Jan 10 01:38, Thomas Robak wrote:
> Querying tables encoded UTF8 containing german umlauts such aus
> Ã,ö,Ã,ä,Ã,ü with ILIKE will only return case-sensitive results.
> For example:
Please see these posts:
http://archives.postgresql.org/pgsql-bugs/2006-01/msg00063.php
http://archives.pos
On Jan 06 10:13, Vic wrote:
> Database have enconding UNICODE.
> Client have KOI8,
> "lower" function not convert to lower case any russian worlds,
> but english words convertable:
This is a known problem related with multi-byte characters. There's
a submitted patch pending for a complete review.
Hi,
A similar topic has been discussed before on pgsql-sql mailing list:
Subject: SELECT very slow Thomas Kellerer
URL: http://archives.postgresql.org/pgsql-sql/2005-06/msg00118.php
Regards.
On 7/6/05, Denis Vlasenko <[EMAIL PROTECTED]> wrote:
> Bug reference: 1756
> Logged by: Den
12 matches
Mail list logo
