date:20060803

[BUGS] BUG #2554: ILIKE operator works incorrectly

2006-08-03 Thread Jarosï¿½aw Bojar


The following bug has been logged online:

Bug reference:  2554
Logged by:  JarosÃÂaw Bojar
Email address:  [EMAIL PROTECTED]
PostgreSQL version: 8.1.4
Operating system:   i386-redhat-linux-gnu, compiled by GCC
i386-redhat-linux-gcc (GCC) 4.1.0
Description:ILIKE operator works incorrectly
Details: 

ILIKE operator works incorrectly with UTF8 encoding and Polish characters.
Consider following SQL statements:

CREATE DATABASE test ENCODING='UTF8';
\c test
CREATE TABLE the_table (val VARCHAR(50));
INSERT INTO the_table (val) VALUES ('ÃÂwiat');
INSERT INTO the_table (val) VALUES ('ÃÂÃÂka');
INSERT INTO the_table (val) VALUES ('ÃÂma');
INSERT INTO the_table (val) VALUES ('abc');
INSERT INTO the_table (val) VALUES ('ABC');

Without Polish characters ILIKE works correctly:
SELECT * FROM the_table WHERE val ilike 'abc';
 val
-
 abc
 ABC
(2 rows)

But with Polish characters it does not work correctly. Following queries
should give single row results, but they do not return any rows:

SELECT * FROM the_table WHERE val ilike 'ÃÂwiat';
 val
-
(0 rows)

SELECT * FROM the_table WHERE val ilike 'ÃÂÃÂka';
 val
-
(0 rows)

SELECT * FROM the_table WHERE val ilike 'ÃÂma';
 val
-
(0 rows)

On the contrary functions like UPPER work correctly with Polish characters
and following queries produce correct results:

SELECT * FROM the_table WHERE UPPER(val) like UPPER('ÃÂwiat');
  val
---
 ÃÂwiat
(1 row)

 SELECT * FROM the_table WHERE UPPER(val) like UPPER('ÃÂma');
 val
-
 ÃÂma
(1 row)

SELECT * FROM the_table WHERE UPPER(val) like UPPER('ÃÂÃÂka');
 val
--
 ÃÂÃÂka
(1 row)

The bug is also present in PostgreSQL 8.1.0 on Windows XP.


---(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 #2561: Manual is wrong: You can't grant a group to

2006-08-03 Thread Brian Hurt





Alvaro Herrera wrote:

  Brian Hurt wrote:

  
  
The manual page for grant here:

http://www.postgresql.org/docs/8.1/interactive/sql-grant.html

indicates that you can grant a group to public.  The discussion of
priveleges here:

http://www.postgresql.org/docs/8.1/interactive/privileges.html

indicates that you can't, and experiment with 8.01 confirms that you can't
as well.  I'm assuming this is a cut and paste error with the documentation.

  
  
Why are you trying 8.1 docs against 8.0 software?

  

Sorry- my typo.  System is 8.1, not 8.0.1.

Did this work in 8.0?

Brian

[BUGS] unsubscribe

2006-08-03 Thread Wade Klaver

unsubscribe
-- 
Wade Klaver
Wavefire Technologies Corporation
GPG Public Key at http://archeron.wavefire.com

/"\   ASCII Ribbon Campaign  .
\ / - NO HTML/RTF in e-mail  .
 X  - NO Word docs in e-mail .
/ \ -

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org

[BUGS] Patch to allow C extension modules to initialize/finish

2006-08-03 Thread Ralf S. Engelschall

PostgreSQL provides a way to load C extension modules with its internal
FMGR. Unfortunately there is no portable way for an extension module to
initialize (directly after the pg_dlopen() of the DSO) and to finish
(directly before the pg_dlclose() of the DSO). This way it is mostly
impossible to write a more complex extension module in a portable way.

The only to me known workarounds are either to call an own
initialization function at the start of _EVERY_ exported function
manually (works, but is ugly and especially doesn't work for the
finishing function!) or to leverage some platform specific hacks like
the implicitly called _init and _fini functions (is what the ODBC
extension module currently does, but is horribly platform specific and
not portable).

Hence I propose the patch below (applies to PostgreSQL 8.1.4) which
mimics the dlopen(3) and dlclose(3) behaviour of some Unix platforms
and resolves and calls _PG_init and _PG_fini functions of an extension
module right after/before the pg_dlopen/pg_dlclose calls in the FMGR.
This is both a fully portable solution and fully backward compatible to
existing and forthcoming extension modules (except they really would
have _PG_init and _PG_fini functions already defined).

   Ralf S. Engelschall
   [EMAIL PROTECTED]
   www.engelschall.com

Index: src/backend/utils/fmgr/dfmgr.c
--- src/backend/utils/fmgr/dfmgr.c.orig 2005-10-15 04:49:32 +0200
+++ src/backend/utils/fmgr/dfmgr.c  2006-08-02 20:48:48 +0200
@@ -60,6 +60,10 @@
 static char *expand_dynamic_library_name(const char *name);
 static char *substitute_libpath_macro(const char *name);

+/* types for PostgreSQL-specific DSO init/fini functions */
+typedef void (*PG_init_t)(void);
+typedef void (*PG_fini_t)(void);
+
 /*
  * Load the specified dynamic-link library file, and look for a function
  * named funcname in it.  (funcname can be NULL to just load the file.)
@@ -82,6 +86,7 @@
char   *load_error;
struct stat stat_buf;
char   *fullname;
+   PG_init_t *PG_init;

fullname = expand_dynamic_library_name(filename);
if (!fullname)
@@ -146,6 +151,13 @@
fullname, load_error)));
}

+   /* optionally give the DSO a chance to initialize by calling a
+  PostgreSQL-specific (and this way portable) "_PG_init" 
function
+  similar to what dlopen(3) implicitly does with "_init" on 
some
+  Unix platforms. */
+   if ((PG_init = (PG_init_t *)pg_dlsym(file_scanner->handle, 
"_PG_init")) != NULL)
+   (*PG_init)();
+
/* OK to link it into list */
if (file_list == NULL)
file_list = file_scanner;
@@ -192,6 +204,7 @@
   *nxt;
struct stat stat_buf;
char   *fullname;
+   PG_fini_t *PG_fini;

fullname = expand_dynamic_library_name(filename);
if (!fullname)
@@ -224,6 +237,14 @@
else
file_list = nxt;
clear_external_function_hash(file_scanner->handle);
+
+   /* optionally give the DSO a chance to finish by calling
+  a PostgreSQL-specific (and this way portable) 
"_PG_fini"
+  function similar to what dlopen(3) implicitly does 
with
+  "_fini" on some Unix platforms. */
+   if ((PG_fini = (PG_init_t 
*)pg_dlsym(file_scanner->handle, "_PG_fini")) != NULL)
+   (*PG_fini)();
+
pg_dlclose(file_scanner->handle);
free((char *) file_scanner);
/* prv does not change */


---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [BUGS] Patch to allow C extension modules to initialize/finish

2006-08-03 Thread tomas

On Wed, Aug 02, 2006 at 09:04:11PM +0200, Ralf S. Engelschall wrote:
> PostgreSQL provides a way to load C extension modules with its internal
> FMGR. Unfortunately there is no portable way for an extension module to
> initialize (directly after the pg_dlopen() of the DSO) and to finish
> (directly before the pg_dlclose() of the DSO). [...]

Cool, but...

[...]

> +
> + /* optionally give the DSO a chance to finish by calling
> +a PostgreSQL-specific (and this way portable) 
> "_PG_fini"
> +function similar to what dlopen(3) implicitly does 
> with
> +"_fini" on some Unix platforms. */
> + if ((PG_fini = (PG_init_t 
> *)pg_dlsym(file_scanner->handle, "_PG_fini")) != NULL)
^
> + (*PG_fini)();
> +
>   pg_dlclose(file_scanner->handle);
>   free((char *) file_scanner);
>   /* prv does not change */

shouldn't that be PG_fini_t?

(yeah, those nitpickers, especially those who are mostly silent
bystanders ;)

But I'd support the idea myself.

Thanks
-- tomas


signature.asc
Description: Digital signature

Re: [BUGS] BUG #2554: ILIKE operator works incorrectly

2006-08-03 Thread Peter Eisentraut

JarosÅaw Bojar wrote:
> ILIKE operator works incorrectly with UTF8 encoding and Polish
> characters.

What does SHOW lc_collate say?

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org

Re: [BUGS] BUG #2554: ILIKE operator works incorrectly

2006-08-03 Thread Tom Lane

Peter Eisentraut <[EMAIL PROTECTED]> writes:
> JarosÅaw Bojar wrote:
>> ILIKE operator works incorrectly with UTF8 encoding and Polish
>> characters.

> What does SHOW lc_collate say?

Even if the locale is set right, iwchareq() is completely broken
for multibyte charsets: it's trying to apply the system's tolower()
to a pg_wchar, which is highly unlikely to work.  This has been a
known problem for awhile, but no one's stepped up to fix it.

regards, tom lane

---(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 #2554: ILIKE operator works incorrectly

Re: [BUGS] BUG #2561: Manual is wrong: You can't grant a group to

[BUGS] unsubscribe

[BUGS] Patch to allow C extension modules to initialize/finish

Re: [BUGS] Patch to allow C extension modules to initialize/finish

Re: [BUGS] BUG #2554: ILIKE operator works incorrectly

Re: [BUGS] BUG #2554: ILIKE operator works incorrectly

7 matches

Site Navigation

Mail list logo

Footer information