Re: [BUGS] Stack not being popped correctly (was: Re: [HACKERS] plpgsql lacks generic identifier for record in triggers...)
Which, doesn't work as expected as it seems as though there's something left behind on the stack that shouldn't be. Here's the case to reproduce (doesn't involve pgmemcache): test=# CREATE FUNCTION t5_func() RETURNS TRIGGER AS 'BEGIN EXECUTE TRUE; RETURN NULL; END;' LANGUAGE 'plpgsql'; What are you expecting "execute true" to do? Behave the same as PERFORM? Ugh, how humiliating. When writing my pgmemcache presentation, I erroneously wrote EXECUTE instead of PERFORM. When sending off that little flurry of emails, I was updating my pgmemcache presentation and subconsciously propagated the error w/o even thinking about it. :-/ Thanks, I'll take that pumpkin pie on my face. -sc -- Sean Chittenden ---(end of broadcast)--- TIP 3: 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
Re: [BUGS] equal operator fails on two identical strings if initdb
Kent Tong <[EMAIL PROTECTED]> writes: > You mean the OS fails to convert unicode strings to Big5 or the > OS assumes the bytes are already in Big5? The latter. > It is the locale used for initdb or the default system locale > set in Windows that is used by the collation routines that you > mentioned above? The former. The real problem here, IMHO, is that Postgres allows you to select a "database encoding" setting that is different from the encoding implied by the initdb locale (ie, the LC_CTYPE setting). If you make this mistake, PG will carefully store data byte sequences in the specified "database encoding" ... and then pass them to strcoll() for comparison ... and strcoll() will assume that the data is in the encoding associated with LC_CTYPE. This is partially bad design on our part (we should really not have invented a per-database encoding selection when the locale setting is not per-database) and partially bad design on the part of the C standard (which doesn't provide any very sane way to find out what encoding is implied by an LC_CTYPE setting). I think the only real fix is to abandon the C library's locale routines and find or write our own library with a better API. This has been on the TODO list for a long time but no one's quite wished to face up to doing it ... In the meantime, make sure your encoding setting agrees with the LC_CTYPE value that initdb used. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] equal operator fails on two identical strings if initdb
Peter Eisentraut wrote: On a POSIX system, you can do $ LC_ALL= locale charmap and verify manually that the printed charmap (= character set encoding) matches what you use in PostgreSQL. I don't know whether an equivalent interface exists on Windows. Right, there is no such command. Reading and writing Unicode is not a problem. But if you run the string comparison operators, PostgreSQL passes the Unicode strings from your database to the operating system's collation routines, which will compare them thinking they are Big5 (or whatever) strings, which will result in the random behavior you observed. You need to set an appropriate locale so that the operating system also thinks they are in Unicode. You mean the OS fails to convert unicode strings to Big5 or the OS assumes the bytes are already in Big5? It is the locale used for initdb or the default system locale set in Windows that is used by the collation routines that you mentioned above? I just double checked my config and found that the default locale is US english. The "supported languages" are: * Traditional Chinese (default) * Simplified Chinese * Western Europe and United States. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] Stack not being popped correctly (was: Re: [HACKERS] plpgsql lacks generic identifier for record in triggers...)
Sean Chittenden <[EMAIL PROTECTED]> writes: > Which, doesn't work as expected as it seems as though there's something > left behind on the stack that shouldn't be. Here's the case to > reproduce (doesn't involve pgmemcache): > test=# CREATE FUNCTION t5_func() RETURNS TRIGGER AS 'BEGIN EXECUTE > TRUE; RETURN NULL; END;' LANGUAGE 'plpgsql'; What are you expecting "execute true" to do? The argument of EXECUTE is a string, not a boolean, and it's supposed to be a string that looks like a SQL command. The result > ERROR: syntax error at or near "t" at character 1 > QUERY: t > CONTEXT: PL/pgSQL function "t5_func" line 1 at execute statement > LINE 1: t > ^ is pretty much what I'd expect considering that plpgsql will do whatever it takes to coerce the expression result to text. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[BUGS] Stack not being popped correctly (was: Re: [HACKERS] plpgsql lacks generic identifier for record in triggers...)
[snip] Err... wait, this is a classic case of send first then
finishing to pondering the gripe.
And sending a reply to ones self without actually testing my suggestion.
db=# CREATE FUNCTION schma.tbl_inval() RETURNS TRIGGER AS 'BEGIN
EXECUTE public.mc_init();
EXECUTE public.mc_delete(''mc_key'');
RETURN NULL;
END;' LANGUAGE 'plpgsql';
db=# CREATE TRIGGER tbl_inval_trg AFTER INSERT OR UPDATE OR DELETE ON
schma.tbl FOR EACH STATEMENT EXECUTE PROCEDURE schma.tbl_inval();
Which, doesn't work as expected as it seems as though there's something
left behind on the stack that shouldn't be. Here's the case to
reproduce (doesn't involve pgmemcache):
test=# CREATE TABLE t5 (i int);
Time: 35.294 ms
test=# CREATE FUNCTION t5_func() RETURNS TRIGGER AS 'BEGIN EXECUTE
TRUE; RETURN NULL; END;' LANGUAGE 'plpgsql';
Time: 101.701 ms
test=# CREATE TRIGGER t5_func_trg AFTER INSERT ON t5 FOR EACH STATEMENT
EXECUTE PROCEDURE t5_func();
Time: 62.345 ms
test=# INSERT INTO t5 VALUES (1);
ERROR: syntax error at or near "t" at character 1
QUERY: t
CONTEXT: PL/pgSQL function "t5_func" line 1 at execute statement
LINE 1: t
^
Doh! Can someone with plpgsql foo look into this? -sc
--
Sean Chittenden
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
Re: [BUGS] BUG #1328: psql don't accept some valid PGCLIENTENCODING values
"PostgreSQL Bugs List" <[EMAIL PROTECTED]> writes: > With PGCLIENTENCODING=KOI8 and server encoding UNICODE > psql do not starts and print this message: > psql: FATAL: invalid value for parameter "client_encoding": "KOI8" Found the problem ... it's something I broke last week :-(. It's fixed now in CVS tip. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [BUGS] BUG #1328: psql don't accept some valid PGCLIENTENCODING values
"PostgreSQL Bugs List" <[EMAIL PROTECTED]> writes: > With PGCLIENTENCODING=KOI8 and server encoding UNICODE > psql do not starts and print this message: > psql: FATAL: invalid value for parameter "client_encoding": "KOI8" Odd ... it Works For Me: $ PGCLIENTENCODING=KOI8 psql regression Welcome to psql 8.0.0beta4, the PostgreSQL interactive terminal. Type: \copyright for distribution terms \h for help with SQL commands \? for help with psql commands \g or terminate with semicolon to execute query \q to quit regression=# \encoding KOI8 regression=# What locale settings are you using? regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] equal operator fails on two identical strings if initdb
Kent Tong wrote: > Is there any way to check? On a POSIX system, you can do $ LC_ALL= locale charmap and verify manually that the printed charmap (= character set encoding) matches what you use in PostgreSQL. I don't know whether an equivalent interface exists on Windows. > I have other programs reading and writing Unicode on this > computer without problems. Reading and writing Unicode is not a problem. But if you run the string comparison operators, PostgreSQL passes the Unicode strings from your database to the operating system's collation routines, which will compare them thinking they are Big5 (or whatever) strings, which will result in the random behavior you observed. You need to set an appropriate locale so that the operating system also thinks they are in Unicode. > Are you using the locale routines in mingw? I believe we do. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 3: 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 #1328: psql don't accept some valid PGCLIENTENCODING values
The following bug has been logged online: Bug reference: 1328 Logged by: kaaos Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0 Beta Operating system: Linux kaaos 2.6.9 #3 Tue Nov 23 13:12:08 MSK 2004 i686 Intel(R) Celeron(R) CPU 1.70GHz GenuineIntel GNU/Linux Description:psql don't accept some valid PGCLIENTENCODING values Details: Hello! First of all, sorry for my English :(. The problem: With PGCLIENTENCODING=KOI8 and server encoding UNICODE psql do not starts and print this message: psql: FATAL: invalid value for parameter "client_encoding": "KOI8" But, if I unset PGCLIENTENCODING, and in psql enter: template1=# \encoding KOI8 then psql accept client encoding: template1=# \encoding KOI8 template1=# show client_encoding; client_encoding - KOI8 (1 row) 'select version()' output: PostgreSQL 8.0.0beta5 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 3.4.3 Thank you. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] equal operator fails on two identical strings if initdb
Peter Eisentraut wrote: Here is a test (run in pgadmin III): 1. createdb db1 -E Unicode Probably your locale does not support Unicode. You need to pick an encoding that matches your locale or vice versa. Is there any way to check? I have other programs reading and writing Unicode on this computer without problems. BTW, the locale for traditional chinese in postgresql.conf is set to "traditional-chinese" literally. Shouldn't it be zh_TW? That depends on what locale names the Windows operating system understands. Are you using the locale routines in mingw? ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [BUGS] equal operator fails on two identical strings if initdb uses the traditional chinese locale
Kent Tong wrote: > I'm running PostgreSQL v8 beta4 on Win2K. The default language > selected in Win2K is Big5. Big5 is an encoding, not a language. > I am using the Windows installer to install it. Everything is > left as default except that the locale for initdb is set to > "traditional-chinese". > > Here is a test (run in pgadmin III): > 1. createdb db1 -E Unicode Probably your locale does not support Unicode. You need to pick an encoding that matches your locale or vice versa. > BTW, the locale for traditional chinese in postgresql.conf is > set to "traditional-chinese" literally. Shouldn't it be > zh_TW? That depends on what locale names the Windows operating system understands. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[BUGS] equal operator fails on two identical strings if initdb uses the traditional chinese locale
Hi,
I'm running PostgreSQL v8 beta4 on Win2K. The default language
selected in Win2K is Big5.
I am using the Windows installer to install it. Everything is
left as default except that the locale for initdb is set to
"traditional-chinese".
Here is a test (run in pgadmin III):
1. createdb db1 -E Unicode
2. psql db1
3. create table t1 ( s varchar(20) primary key );
4. insert into t1 values('xyz'); Note that x, y and z are all
Chinese characters.
5. select * from t1; It shows that record just fine.
6. select * from t1 where s='xyz'; It fails to find that record.
7. select * from t1 where s like 'xy%'; It finds that record.
If I reinstall pgsql but leave the locale as the default ("C"),
then the above test passes.
BTW, the locale for traditional chinese in postgresql.conf is
set to "traditional-chinese" literally. Shouldn't it be
zh_TW?
Thanks!
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
