[BUGS] weird strncmp bug while executing trigger?
If PostgreSQL failed to compile on your computer or you found a bug that
is likely to be specific to one platform then please fill out this form
and e-mail it to [EMAIL PROTECTED]
To report any other bug, fill out the form below and e-mail it to
[EMAIL PROTECTED]
If you not only found the problem but solved it and generated a patch
then e-mail it to [EMAIL PROTECTED] instead. Please use the
command "diff -c" to generate the patch.
You may also enter a bug report at http://www.postgresql.org/ instead of
e-mail-ing this form.
POSTGRESQL BUG REPORT TEMPLATE
Your name : Anand Ranganathan
Your email address : [EMAIL PROTECTED]
System Configuration
-
Architecture (example: Intel Pentium) : Intel Pentium
Operating System (example: Linux 2.0.26 ELF) : Linux 2.2.19 ELF (Debian unstable)
PostgreSQL version (example: PostgreSQL-7.1.3): PostgreSQL-7.2.1
Compiler used (example: gcc 2.95.2) : gcc 2.95.4 20011002 (Debian
prerelease)
Please enter a FULL description of your problem:
When I run the select statement given below, the postgres server dies on
a SIGSEGV. This is quite annoying.
Please describe a way to repeat the problem. Please try to provide a
concise reproducible example, if at all possible:
--
Between the dashed lines is the output of pg_dump
pg_dump output---
--
-- Selected TOC Entries:
--
\connect - anand
--
-- TOC Entry ID 11 (OID 16623)
--
-- Name: "plpgsql_call_handler" () Type: FUNCTION Owner: anand
--
CREATE FUNCTION "plpgsql_call_handler" () RETURNS opaque AS
'/bp/vendor/lib/plpgsql.so', 'plpgsql_call_handler' LANGUAGE 'C';
--
-- TOC Entry ID 12 (OID 16624)
--
-- Name: plpgsql Type: PROCEDURAL LANGUAGE Owner:
--
CREATE TRUSTED PROCEDURAL LANGUAGE 'plpgsql' HANDLER "plpgsql_call_handler"
LANCOMPILER 'PL/pgSQL';
--
-- TOC Entry ID 13 (OID 16625)
--
-- Name: "insert_comment" () Type: FUNCTION Owner: anand
--
CREATE FUNCTION "insert_comment" () RETURNS opaque AS 'DECLARE profile RECORD;
BEGIN
SELECT INTO profile * FROM uid_profile WHERE uid = new.uid;
IF profile.signature <>
THEN
new.description = new.description || ''-- ''
|| profile.signature;
END IF;
RETURN new;
END;' LANGUAGE 'plpgsql';
--
-- TOC Entry ID 4 (OID 16626)
--
-- Name: uid_profile Type: TABLE Owner: anand
--
CREATE TABLE "uid_profile" (
"uid" integer NOT NULL,
"username" text,
"karma" integer DEFAULT 0,
"user_type" character(1) DEFAULT 'R',
"last_access" timestamp with time zone DEFAULT "timestamp"('now'::text),
"mod_worthy" integer DEFAULT 0,
"min_threshold" integer DEFAULT 1,
"display_type" character(1) DEFAULT 'F',
"signature" text DEFAULT '',
"timezone" text DEFAULT 'PST',
"spam_mail" text DEFAULT '',
Constraint "uid_profile_pkey" Primary Key ("uid")
);
--
-- TOC Entry ID 2 (OID 16768)
--
-- Name: comments_cid_seq Type: SEQUENCE Owner: anand
--
CREATE SEQUENCE "comments_cid_seq" start 1 increment 1 maxvalue 2147483647 minvalue 1
cache 1;
--
-- TOC Entry ID 5 (OID 16770)
--
-- Name: comments Type: TABLE Owner: anand
--
CREATE TABLE "comments" (
"aid" integer,
"subject" text,
"description" text,
"uid" integer,
"when_posted" timestamp with time zone DEFAULT "timestamp"('now'::text),
"modvalue" integer DEFAULT 1,
"lastmod" integer DEFAULT 1,
"parent" integer DEFAULT 0,
"posting_uid" integer,
"posting_user" text,
"cid" integer DEFAULT nextval('"comments_cid_seq"'::text) NOT NULL,
Constraint "comments_pkey" Primary Key ("cid")
);
--
-- Data for TOC Entry ID 14 (OID 16626)
--
-- Name: uid_profile Type: TABLE DATA Owner: anand
--
COPY "uid_profile" FROM stdin;
101 axl rose31 E 2002-03-08 19:35:38-08 70 1 F
PST
\.
--
-- Data for TOC Entry ID 15 (OID 16770)
--
-- Name: comments Type: TABLE DATA Owner: anand
--
COPY "comments" FROM stdin;
\.
--
-- TOC Entry ID 6 (OID 17046)
--
-- Name: "comments_uid_index" Type: INDEX Owner: anand
--
CREATE INDEX comments_uid_index ON comments USING btree (uid);
--
-- TOC Entry ID 7 (OID 17047)
--
-- Name: "comments_modvalue_index" Type: INDEX Owner: anand
--
CREATE INDEX comments_modvalue_index ON comments USING btree (modvalue);
--
-- TOC Entry ID 8 (OID 17048)
--
-- Name: "comments_parent_index" Type: INDEX
[BUGS] psql 7.2.1: \d (alone) missing from \?
This problem is so simple, the subject pretty much says it all. For the sake of completeness, I'm running PostgreSQL 7.2.1 as supplied by RedHat in their 7.3 release for i386. This bug report pertains only to the psql front end. The command \d all by itself (with no arguments) lists all relations along with the type and owner. This fact is, however, not mentioned in the help message you get with \?, which lists loads of other things you can with \d but forgets to mention \d all by itself. -- Jay Berkenbilt <[EMAIL PROTECTED]> http://www.ql.org/q/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] [Fwd: [GENERAL] [Please Help!!!!!!!!] Problem in Chinese
Hi Tatsue Ishii, Ok, but problem is, when i try encode with unicode, it also reject me invalid UNICODE charater :-( I already try few client, like borland's SQL explorer, zde... and restore program come with postgresql... Sorry, i would like to a special request. After i read preious message from you to Gene Leung, let me fully understand under EUC_TW rule , postgresql should reject me (input such invalid charaters). So i request a special patch that could to support Big5 or disable the validation. If postgres do not support Big5, that is big problem in chinese... Please help. Thanks for your quick response ( i have not response in General Mailling list :-( , may be no one using postgresql in chinese [Big5].) Gordon Tatsuo Ishii wrote: >Honestly I'm tired of this kind of complains. Please verify your >"correct" EUC_TW character sequences first. ¤¤¤å¦r" >cannot be correct EUC_TW at all. I have already shown >Gene Leung "rules to verify your EUC_TW character sequences". >See followings. > >BTW, I have no idea what Pgadmin II is. Are you sure that it supports >EUC_TW? I suspect it only supports Big5. (EUC_TW and Big5 are >completely different beasts). > >--- >Ok, here are some rules to verify EUC_TW characters: > >(1) if the first byte is 0x8e, then the 8th bit of following three >bytes must be set > >(2) else if the first byte is 0x8f, then the 8th bit of following two >bytes must be set > >(3) else if the 8th bit of the first byte is set, then the 8th bit of >following one bytes must be set > >(4) else (that means the 8th bit of the first byte is not set) then >that must be an ASCII character. > >Apparently 0xa672 does not satisfy all of above. > >-- >Tatsuo Ishii > > _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ---(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] [Fwd: [GENERAL] [Please Help!!!!!!!!] Problem in Chinese
Tatsuo Ishii wrote: Ok, but problem is, when i try encode with unicode, it also reject me invalid UNICODE charater :-( Show me the entire error message please. Ok... error like this... ERROR : Invalid UNICODE character sequence found (0xe5a672)... the input charater also "¤¤¤å¦r" Actually PostgreSQL does support Big5. To use Big5, set the client encoding to Big5 and set the server(DB) encoding to EUC_TW. PostgreSQL will take care of the conversion between Big5 and EUC_TW. There are several ways to set the client encoding to Big5: SQL: set client_encoding to 'Big5'; from psql: \encoding Big5 using environment variable: export PGCLIENTENCODING=Big5 (example for bash) Hope this helps, -- Tatsuo Ishii O... you are right, i use Pgadmin II , and type SQL by hand ... and add the "set client_encoding to 'Big5';" before insert statement It WORK Thanks... Gordon
Re: [BUGS] weird strncmp bug while executing trigger?
Anand <[EMAIL PROTECTED]> writes: > When I run the select statement given below, the postgres server dies on > a SIGSEGV. This is quite annoying. Hmm ... works for me. You should check that the plpgsql.so mentioned by the CREATE FUNCTION call is the same version of Postgres as your backend. Weird things can happen if an out-of-date plpgsql.so gets loaded. I have not seen this particular behavior reported before, though, so maybe that's not it. regards, tom lane ---(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] [ODBC] "Field is too small"
Webb Sprague wrote: > > I am getting a "field is too small" error in an Access > DB running over ODBC. The field in question is > varchar(32). > > Here is the weird thing: I am inserting into a table > with a rule that sends the result to a different > table. Are you using a DO INSTEAD rule ? Could you send me the Mylog output ? regards, Hiroshi Inoue http://w2422.nsk.ne.jp/~inoue/ ---(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
