Re: [BUGS] BUG #1931: ILIKE and LIKE fails on Turkish locale
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 | ~* -+-+-+-+---+ tr_TR.iso8859-9 | LATIN5 | OK | OK |OK |OK tr_TR.iso8859-9 |UTF8 | OK | OK |OK |OK tr_TR.UTF-8 | LATIN5 | OK | OK | FAILS | FAILS tr_TR.UTF-8 |UTF8 | OK | OK | FAILS | FAILS Also, if you'd wish, I can prepare an ad-hoc regression tests patch for LATIN5 and UTF-8 support of Turkish characters. Regards. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [BUGS] BUG #1931: ILIKE and LIKE fails on Turkish locale
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 patch. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [BUGS] BUG #1931: ILIKE and LIKE fails on Turkish locale
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 patch.
I couldn't understand why you're so aggressive. I'm just trying to help.
And, IMNSHO, posted test results are quite helpful to determine the
exact problem.
As I understand from the tests, ILIKE and ~* don't work properly while
using UTF-8, despite lower() and upper() work without any problem.
Therefore, I've tried to imitate the code of lower() to form a working
iwchareq() method. [Related patch is attached.] It succeded in all of my
previous tests (and plus in regression tests).
As you can see, it's a quite ad-hoc patch. (No win32 support added yet.)
Also, it needs a HAVE_MBTOWC definition too. I just wanted to give it a
V0 speed.
I think, like.c and oracle_compat.c files should be written from
scratch by somebody with more experience. They look like deprecated in
some aspects. (For instance, like.c is still using CHARMAX despite Bruce
generalized it as HIGHBIT in c.h)
Regards.
Index: src/backend/utils/adt/like.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/utils/adt/like.c,v
retrieving revision 1.64
diff -c -r1.64 like.c
*** src/backend/utils/adt/like.c5 Mar 2006 15:58:42 - 1.64
--- src/backend/utils/adt/like.c15 Jun 2006 15:36:19 -
***
*** 19,25
--- 19,33
#include ctype.h
+ #ifdef HAVE_WCHAR_H
+ #include wchar.h
+ #endif
+ #ifdef HAVE_WCTYPE_H
+ #include wctype.h
+ #endif
+
#include mb/pg_wchar.h
+ #include utils/pg_locale.h
#include utils/builtins.h
***
*** 70,109
* If they match, returns 1 otherwise returns 0.
*
*/
- #define CHARMAX 0x80
static int
iwchareq(char *p1, char *p2)
{
! pg_wcharc1[2],
! c2[2];
! int l;
!
/*
!* short cut. if *p1 and *p2 is lower than CHARMAX, then we could assume
!* they are ASCII
*/
! if ((unsigned char) *p1 CHARMAX (unsigned char) *p2 CHARMAX)
! return (tolower((unsigned char) *p1) == tolower((unsigned char)
*p2));
! /*
!* if one of them is an ASCII while the other is not, then they must be
!* different characters
!*/
! else if ((unsigned char) *p1 CHARMAX || (unsigned char) *p2 CHARMAX)
! return 0;
! /*
!* ok, p1 and p2 are both CHARMAX, then they must be multibyte
!* characters
!*/
! l = pg_mblen(p1);
! (void) pg_mb2wchar_with_len(p1, c1, l);
! c1[0] = tolower(c1[0]);
! l = pg_mblen(p2);
! (void) pg_mb2wchar_with_len(p2, c2, l);
! c2[0] = tolower(c2[0]);
! return (c1[0] == c2[0]);
}
#define CHAREQ(p1, p2) wchareq(p1, p2)
--- 78,119
* If they match, returns 1 otherwise returns 0.
*
*/
static int
iwchareq(char *p1, char *p2)
{
! #if defined(HAVE_WCSTOMBS) defined(HAVE_TOWLOWER)
/*
!* While lowercasing, applying same rules as in lower().
*/
! if (pg_database_encoding_max_length() 1 !lc_ctype_is_c())
! {
! wchar_t c1, c2;
! int l1 = mbtowc(c1, p1, MB_CUR_MAX);
! int l2 = mbtowc(c2, p2, MB_CUR_MAX);
! if (l1 == (size_t) -1 || l2 == (size_t) -1)
! {
! /*
!* Invalid multibyte character encountered. (Shouldn't
happen.)
!*/
! ereport(ERROR,
!
(errcode(ERRCODE_CHARACTER_NOT_IN_REPERTOIRE),
!errmsg(invalid multibyte character
for locale)));
! }
! Assert(l1 = (size_t) MB_CUR_MAX l2 = (size_t) MB_CUR_MAX);
!
! return (towlower(c1) == towlower(c2));
! }
! else
! #endif
! {
! charc1 = tolower((unsigned char) *p1);
! charc2 = tolower((unsigned char) *p2);
!
! return (c1 == c2);
! }
}
#define CHAREQ(p1, p2) wchareq(p1, p2)
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
[BUGS] BUG #2480: Installation Error of RMP for RHEL4
The following bug has been logged online: Bug reference: 2480 Logged by: Tetsuo Sakata Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1.4 Operating system: RedHat AS4 Description:Installation Error of RMP for RHEL4 Details: Hi, My name is Tetsuo Sakata. I found an error when I tried to install an RPM postgresql-docs-8.1.4-1PGDG.i686.rpm which was downloaded via http://www.postgresql.org/ftp/binary/v8.1.4/linux/rpms/redhat/rhel-as-4/. I typed an rpm command to see the error message as follows. [EMAIL PROTECTED] retry2]# rpm -ivh postgresql-docs-8.1.4-1PGDG.i686.rpm error: postgresql-docs-8.1.4-1PGDG.i686.rpm: MD5 digest: BAD Expected(a6f3196317b296ef555f47f343a6871b) !=(b9dcbf1533565efb9d629e25a4224906) error: postgresql-docs-8.1.4-1PGDG.i686.rpm cannot be installed [EMAIL PROTECTED] retry2]# I'll be pleased if you cope with the trouble. Thanks in advance, Tetsuo Sakata. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[BUGS] BUG #2482: Wrong result in timestamp_in, timestamptz_in, date_in
The following bug has been logged online: Bug reference: 2482 Logged by: Alexander Galler Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1.3 Operating system: Windows XP Description:Wrong result in timestamp_in, timestamptz_in, date_in Details: SET SESSION DateStyle TO ISO, YMD; select '20.01.01 BC'::timestamp; Result: 2020-01-01 00:00:00 BC I want 20-01-01 00:00:00 BC select '20.01.01 BC'::timestamptz Result: 2020-01-01 00:00:00+06:11 BC I want 20-01-01 00:00:00+06:11 BC select '20.01.01 BC'::date Result: 2020-01-01 BC I want 20-01-01 BC ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] Compile Errors, 8.1.4 On Solaris 8 x86
Is there any particular file you'd care to see? Thanks, Guy -Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 13, 2006 5:57 PM To: [EMAIL PROTECTED] Cc: pgsql-bugs@postgresql.org Subject: Re: [BUGS] Compile Errors, 8.1.4 On Solaris 8 x86 Guy [EMAIL PROTECTED] writes: I'm having some difficulty getting this to compile on a Solaris 8 x86 platform. You haven't showed us the actual problem (hint: the first error message is usually the interesting one, not the last one). regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[BUGS] Unable to set priveleges of user
We actually want to access database of postgresql through a java program.How do we make the user in postgresql with a encrypted password and with proper priveleges.Please provide the exact syntax for that. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] BUG #2481: select from table's join with geometries doesn't go
Emilia Venturato [EMAIL PROTECTED] writes: Postgis developper said it could be a postgresql bug. Or it could be a postgis bug. Without a test case we can use to reproduce the problem, it's all speculation. Please send a complete, self-contained test case... regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] BUG #2482: Wrong result in timestamp_in, timestamptz_in, date_in
Alexander Galler [EMAIL PROTECTED] writes: select '20.01.01 BC'::timestamp; Result: 2020-01-01 00:00:00 BC I want 20-01-01 00:00:00 BC You can write select '0020.01.01 BC'::timestamp; I agree it seems like a bug that the 'yy'-'20yy' conversion is applied to BC dates. The code appears to try to avoid that, but I think it's confused in this case because 'BC' hasn't been scanned yet. regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [BUGS] BUG #2481: select from table's join with geometries doesn't go
On Thu, Jun 15, 2006 at 11:48:37PM -0400, Tom Lane wrote: Emilia Venturato [EMAIL PROTECTED] writes: Postgis developper said it could be a postgresql bug. Or it could be a postgis bug. Without a test case we can use to reproduce the problem, it's all speculation. Please send a complete, self-contained test case... This report resembles a message Emilia posted in postgis-users a couple of weeks ago. The only public discussion is a request for the PostGIS version and copy of the data: http://postgis.refractions.net/pipermail/postgis-users/2006-June/012281.html http://postgis.refractions.net/pipermail/postgis-users/2006-June/012282.html Emilia, did you and Sandro (strk) have off-list discussion about this problem? What do version() and postgis_full_version() return? What happens if you select the geometry column without a join, i.e., SELECT the_geom FROM wwf_terr_ecos_multigeom WHERE ...? Do you get the segmentation fault with the original query if you select AsText(the_geom) or AsEWKT(the_geom) instead of just the_geom? Did the segmentation fault leave a core dump in your $PGDATA directory or somewhere beneath it? If not then you might need to adjust your coredumpsize resource limit. -- Michael Fuhr ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
