[BUGS] BUG #3413: character string or multibyte character to char
The following bug has been logged online:
Bug reference: 3413
Logged by: Toru SHIMOGAKI
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.4
Operating system: Red Hat Enterprise Linux AS4
Description:character string or multibyte character to char
Details:
When a character string or a multibyte character is inserted to char
column, no error occurs. Is this a bug? Should it be checked as not single
character in charin(), charrecv() and charout()?
Anyway, I can't find any spec descriptions in the following document;
http://www.postgresql.org/docs/8.2/static/datatype-character.html
Best regards,
postgres=# select version();
version
---
PostgreSQL 8.2.4 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 3.4.6
20060404 (Red Hat 3.4.6-3)
(1 row)
postgres=# create table test(flag char);
CREATE TABLE
postgres=# \d test
Table public.test
Column | Type | Modifiers
++---
flag | char |
postgres=# insert into test values('a');
INSERT 0 1
postgres=# insert into test values('bb');
INSERT 0 1
postgres=# insert into test values('e');
INSERT 0 1
postgres=# insert into test values('ã');
INSERT 0 1
postgres=# select * from test;
flag
--
a
b
e
(4 rows)
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
Re: [BUGS] BUG #3413: character string or multibyte character to char
This is a sample patch for charin() and charrecv(). I'm not sure for charout();
it can return non-ASCII character...
Toru SHIMOGAKI wrote:
The following bug has been logged online:
Bug reference: 3413
Logged by: Toru SHIMOGAKI
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.4
Operating system: Red Hat Enterprise Linux AS4
Description:character string or multibyte character to char
Details:
When a character string or a multibyte character is inserted to char
column, no error occurs. Is this a bug? Should it be checked as not single
character in charin(), charrecv() and charout()?
Anyway, I can't find any spec descriptions in the following document;
http://www.postgresql.org/docs/8.2/static/datatype-character.html
Best regards,
postgres=# select version();
version
---
PostgreSQL 8.2.4 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 3.4.6
20060404 (Red Hat 3.4.6-3)
(1 row)
postgres=# create table test(flag char);
CREATE TABLE
postgres=# \d test
Table public.test
Column | Type | Modifiers
++---
flag | char |
postgres=# insert into test values('a');
INSERT 0 1
postgres=# insert into test values('bb');
INSERT 0 1
postgres=# insert into test values('e');
INSERT 0 1
postgres=# insert into test values('あ');
INSERT 0 1
postgres=# select * from test;
flag
--
a
b
e
(4 rows)
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
--
Toru SHIMOGAKI[EMAIL PROTECTED]
NTT Open Source Software Center
Index: src/backend/utils/adt/char.c
===
--- src/backend/utils/adt/char.c(revision 1156)
+++ src/backend/utils/adt/char.c(working copy)
@@ -34,6 +34,11 @@
{
char *ch = PG_GETARG_CSTRING(0);
+ if (ch[0] != '\0' ch[1] != '\0')
+ ereport(ERROR,
+ (errcode(ERRCODE_STRING_DATA_RIGHT_TRUNCATION),
+errmsg(value too long for type \char\)));
+
PG_RETURN_CHAR(ch[0]);
}
@@ -67,6 +72,11 @@
{
StringInfo buf = (StringInfo) PG_GETARG_POINTER(0);
+ if (buf-len 1)
+ ereport(ERROR,
+ (errcode(ERRCODE_STRING_DATA_RIGHT_TRUNCATION),
+errmsg(value too long for type \char\)));
+
PG_RETURN_CHAR(pq_getmsgbyte(buf));
}
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
Re: [HACKERS] [PATCHES] [BUGS] BUG #2704: pg_class.relchecks overflow
Tom Lane wrote: While there's not anything wrong with this proposed patch in itself, I have to admit that I don't see the point. The points are: 1. It is just unpleasant to leave the overflow. 2. It is not easy for users to understand what they should do when they encounter the error message. At least users can't understand that it is because of the upper limit: ERROR: unexpected constraint record found for rel test_a I haven't found such a case in real practice. But I think the limit will be a little closer than that is now, because constraint exclusion is expanded for UPDATE/DELETE in 8.2 and the opportunity of using check constraint will increase . So I investigated the upper limit and found it. By the way, as you said, it would impose an extra burden on message translators and I can understand your opinion. But will it lead directly to the reason that we don't fix it? Best regards, -- Toru SHIMOGAKI[EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [BUGS] BUG #2704: pg_class.relchecks overflow problem
How about this patch? Of course, it might be a rare case that such check is necessary... Toru SHIMOGAKI wrote: The following bug has been logged online: Bug reference: 2704 Logged by: Toru SHIMOGAKI Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1.4 Operating system: Red Hat Enterprise Linux AS 4 Description:pg_class.relchecks overflow problem Details: Hi, pg_class.relchecks is defined as int2. But the upper bound of this value is not checked and it overflows. I found it at the following case: 1. I tried to add check constraints: alter table test_a add check (aaa i); (0 = i = 32767) 2. When I added the 32768th check constraint, the value of pg_class.relchecs became -32768. postgres=# alter table test_a add check ( aaa 32768 ); ALTER TABLE postgres=# select relname, relchecks from pg_class where relname = 'test_a'; relname | relchecks -+--- test_a | -32768 (1 row) 3. The following error message was found when I added the next one: postgres=# alter table test_a add check ( aaa 32769 ); ERROR: unexpected constraint record found for rel test_a postgres=# select relname, relchecks from pg_class where relname = 'test_a'; relname | relchecks -+--- test_a | -32768 (1 row) Best regards, ---(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 -- Toru SHIMOGAKI[EMAIL PROTECTED] diff -cpr postgresql-8.1.5-orig/src/backend/catalog/heap.c postgresql-8.1.5/src/backend/catalog/heap.c *** postgresql-8.1.5-orig/src/backend/catalog/heap.c2006-04-24 10:40:39.0 +0900 --- postgresql-8.1.5/src/backend/catalog/heap.c 2006-10-23 16:50:22.0 +0900 *** AddRelationRawConstraints(Relation rel, *** 1525,1530 --- 1525,1535 continue; Assert(cdef-cooked_expr == NULL); + if (numchecks == 0x7FFF) + ereport(ERROR, + (errcode(ERRCODE_PROGRAM_LIMIT_EXCEEDED), + errmsg(cannot have more than 2^15-1 checks in a table))); + /* * Transform raw parsetree to executable expression. */ ---(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] BUG #2704: pg_class.relchecks overflow problem
The following bug has been logged online: Bug reference: 2704 Logged by: Toru SHIMOGAKI Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1.4 Operating system: Red Hat Enterprise Linux AS 4 Description:pg_class.relchecks overflow problem Details: Hi, pg_class.relchecks is defined as int2. But the upper bound of this value is not checked and it overflows. I found it at the following case: 1. I tried to add check constraints: alter table test_a add check (aaa i); (0 = i = 32767) 2. When I added the 32768th check constraint, the value of pg_class.relchecs became -32768. postgres=# alter table test_a add check ( aaa 32768 ); ALTER TABLE postgres=# select relname, relchecks from pg_class where relname = 'test_a'; relname | relchecks -+--- test_a | -32768 (1 row) 3. The following error message was found when I added the next one: postgres=# alter table test_a add check ( aaa 32769 ); ERROR: unexpected constraint record found for rel test_a postgres=# select relname, relchecks from pg_class where relname = 'test_a'; relname | relchecks -+--- test_a | -32768 (1 row) Best regards, ---(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 #2671: incorrect return value by RULE
The following bug has been logged online: Bug reference: 2671 Logged by: Toru SHIMOGAKI Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1.4/8.2beta1 Operating system: Red Hat Enterprise Linux AS4 Description:incorrect return value by RULE Details: Hi, all; It seems a bug that incorrect return value is displayed if RULE is applied (RULE is always used when users use table partitioning). This is undesirable for some users and applications that want to check return value. The following is the procedure: = postgres=# \d test_p; Table public.test_p Column | Type | Modifiers +-+--- a | integer | Rules: rule_1 AS ON INSERT TO test_p WHERE new.a = 0 DO INSTEAD INSERT INTO test_c1 (a) VALUES (new.a) rule_2 AS ON INSERT TO test_p WHERE new.a 0 DO INSTEAD INSERT INTO test_c2 (a) VALUES (new.a) postgres=# \d test_c1; Table public.test_c1 Column | Type | Modifiers +-+--- a | integer | Inherits: test_p postgres=# \d test_c2; Table public.test_c2 Column | Type | Modifiers +-+--- a | integer | Inherits: test_p postgres=# INSERT INTO test_p VALUES (1); INSERT 0 0 ^^^ The expected result is INSERT 0 1 = At least, this behavior is different from the following discription of INSERT manual; = ... Outputs On successful completion, an INSERT command returns a command tag of the form INSERT oid count The count is the number of rows inserted. If count is exactly one, and the target table has OIDs, then oid is the OID assigned to the inserted row. Otherwise oid is zero. ... = We need some specifications to solve this problem. I think that to fix it seems not so easy, because RULE has DO ALSO/DO INSTEAD and we have to consider them for a query multiple RULES are applied. Are there any good ideas to avoid or fix it? Best regards, -- Toru SHIMOGAKI[EMAIL PROTECTED] NTT Open Source Software Center ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
