Re: [GENERAL] Concerning about Unicode-aware string handling

2012-05-21 Thread Vincas Dargis
I've forgot to mention I'm working on Windows XP SP3 Yes, we are using UTF8 encoding and regexp works wrong. It looks like you replicated that. 2012/5/21 Albe Laurenz : > > I tried it with 9.1.3 on Linux: > > upper() and lower() works fine, no matter what the > database encoding is: > > test=> SE

Re: [GENERAL] Concerning about Unicode-aware string handling

2012-05-21 Thread Vincas Dargis
Sorry I have to write "manual" replay since I've messed up mailing list settings (got "Partial Digest"...). John R Pierce wrote: > your database encoding is UTF8 ? the language or environment you're using to > generate those strings such as 'acząčž' is also UTF8 ? Database created using: initdb

[GENERAL]

2012-05-21 Thread Vincas Dargis
Sorry I have to write "manual" replay since I've messed up mailing list settings (got "Partial Digest"...). John R Pierce wrote: > your database encoding is UTF8 ? the language or environment you're using to > generate those strings such as 'acząčž' is also UTF8 ? Database created using: initdb

[GENERAL] Concerning about Unicode-aware string handling

2012-05-21 Thread Vincas Dargis
Hello, We have problems (currently using 8.4, but also in latest 9.1.3) in our application with Unicode word symbols in Lithuanian ('ąčęėįšųūž'), Russian and of course potentially other languages. For example, regex_replace('acząčž', E'\\W', '', 'g') removes ąčž. lower() and ~* comparison works

Re: [GENERAL] PostgreSQL 8.4 crash on user defined C language function

2012-04-04 Thread Vincas Dargis
Yeah, original example took command from arguments, I simply forgot to revert changes to original. Though it's not the problem, it is something with calling other functions under some kind environment I got. Your test was successful for "obviously it should work" reason, but it's something wro

Re: [GENERAL] PostgreSQL 8.4 crash on user defined C language function

2012-04-04 Thread Vincas Dargis
2012.04.04 20:37, Merlin Moncure rašė: did you remember to set up the V1 calling convention macro? merlin Yes, I did remember. This kind of inconsistency bugs me, why SPI_* works, pmalloc not? Vincas. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes

[GENERAL] PostgreSQL 8.4 crash on user defined C language function

2012-04-04 Thread Vincas Dargis
SORRY FOR DUPLICATE EMAIL, I guess I'm really in pretty bad shape... Hello, I am experimenting with user defined functions in C, though I have problem with stability. It always crash on palloc() call, SPI_tuptable->tupdesc dereference but not on SPI_* calls, for example. Here is one modified ex

[GENERAL]

2012-04-04 Thread Vincas Dargis
Hello, I am experimenting with user defined functions in C, though I have problem with stability. It always crash on palloc() call, SPI_tuptable->tupdesc dereference but not on SPI_* calls. Here is one modified example from documentation: PGDLLIMPORT Datum test(PG_FUNCTION_ARGS) { char *

Re: [GENERAL] regexp_replace - replace non-numbers

2008-10-28 Thread Vincas Dargis
Merlin Moncure wrote: On Tue, Oct 28, 2008 at 10:42 AM, Vincas Dargis <[EMAIL PROTECTED]> wrote: Hello everyone, I have problem with regexp_replace ( PostgreSQL 8.3.1). Please try this crappy string replacement: select regexp_replace('[EMAIL PROTECTED]&^&*()[]-=',

[GENERAL] regexp_replace - replace non-numbers

2008-10-28 Thread Vincas Dargis
at it, thought it looks quite OK in Regex Coatch. ...or maybe there are way for 'no-errorous-blocking' casting? I could easily skip strings witch could not be CAST'ed to bigint, but as long as I get error and aborted transaction, I'm trying this approach. Thanks for com