Обсуждение: Garbage characters for \d table?
Bug summary: PSQL's \d table displaying garbage characters for one table. Severity: Annoyance Reproducability: Poor Version: 7.4.3 on the client, 7.4.1 on the server. Both compiled from source. Platform: SuSE Linux 9.1, Linux Kernel 2.6.7 (client), RH Linux 8.0 on server. Connection btw. client <--> server is over SSH tunnel. When I do a \d on one table in PSQL, I get the following: Table "public.elbs_timekeep" Column | Type | Modifiers -------------------+-----------------------------+----------- 240240240240240240240240tkinit | character varying(8) | 240240240240240240240240tksort | integer | 240240240240240240240240tklast | character varying(20) | 240240240240240240240240tkfirst | character varying(20) | 240240240240240240240240tktitle | character varying(15) | 240240240240240240240240tktmdate | timestamp without time zone | 240240240240240240240240tkloc | character varying(4) | 240240240240240240240240tkemdate | timestamp without time zone | 240240240240240240240240tkinitb | character varying(8) | 240240240240240240240240tglmask | character varying(64) | 240240240240240240240240tkblast | character varying(20) | 240240240240240240240240tkbfirst | character varying(20) | 240240240240240240240240tkstrate | numeric | 240240240240240240240240tkdept | character varying(10) | 240240240240240240240240tksect | character varying(10) | 240240240240240240240240tkschool | character varying(20) | 240240240240240240240240tkgrdate | timestamp without time zone | 240240240240240240240240tkbrdate | timestamp without time zone | 240240240240240240240240tkstdcst | numeric | 240240240240240240240240tprotem | character varying(7) | 240240240240240240240240tkeflag | character varying(1) | 240240240240240240240240tkemail | character varying(50) | 240240240240240240240240tkmoddate | timestamp without time zone | 240240240240240240240240tkmodtime | character varying(8) | 240240240240240240240240tkmoduser | character varying(8) | 240240240240240240240240tkceflag | character varying(1) | This does NOT happen: 1) on other tables; 2) when I use PSQL on the server. Frankly, the circumstances are peculiar enough that I don't expect you to do anything about this bug report; instead I'm filing it in case any related problems crop up with 7.4's PSQL. And, yes, I tried re-connecting in case this was somehow line noise. -- __Aglio Database Solutions_______________ Josh Berkus Consultant josh@agliodbs.com www.agliodbs.com Ph: 415-752-2500 Fax: 415-752-2387 2166 Hayes Suite 200 San Francisco, CA
Folks, > Bug summary: PSQL's \d table displaying garbage characters for one table. > Severity: Annoyance > Reproducability: Poor > Version: 7.4.3 on the client, 7.4.1 on the server. Both compiled from > source. > Platform: SuSE Linux 9.1, Linux Kernel 2.6.7 (client), RH Linux 8.0 on > server. Connection btw. client <--> server is over SSH tunnel. UPDATE: Turns out the garbage characters were actually in the field names themselves. Somehow a previous bad connection caused line breaks to get replaced with unicode garbage when I created the table. It seems like, in PSQL, the use of non-ASCII characters should require quoted identifiers, but apparently not? -- __Aglio Database Solutions_______________ Josh Berkus Consultant josh@agliodbs.com www.agliodbs.com Ph: 415-752-2500 Fax: 415-752-2387 2166 Hayes Suite 200 San Francisco, CA
Josh Berkus <josh@agliodbs.com> writes: > When I do a \d on one table in PSQL, I get the following: > Table "public.elbs_timekeep" > Column | Type | Modifiers > -------------------+-----------------------------+----------- > 240240240240240240240240tkinit | character varying(8) | > 240240240240240240240240tksort | integer | > 240240240240240240240240tklast | character varying(20) | [ scratches head... ] What's the actual names of the columns, as seen in a less broken \d display? I'm wondering if this is a character set encoding conversion gone wild, or some such. What is the database encoding, what is the client encoding (and are they the same in the working and nonworking cases)? The misaligned column headings suggest that each "240" was thought by psql to be a single character. I suspect it is actually an octal 240 byte inside psql (it may or may not be that at the server). The expansion to three characters "240" must be happening after psql prints the data. What terminal program are you using? Is there anything else between you and psql (ssh tunnel, etc)? regards, tom lane
Josh Berkus <josh@agliodbs.com> writes: > UPDATE: Turns out the garbage characters were actually in the field names > themselves. Somehow a previous bad connection caused line breaks to get > replaced with unicode garbage when I created the table. It seems like, in > PSQL, the use of non-ASCII characters should require quoted identifiers, but > apparently not? No, that's deliberate: any byte >= octal 200 is allowed as part of an unquoted identifier. Non-English-speaking users would get quite upset with us if they had to quote, say, e-acute to use it in an identifier. Ideally I suppose we'd restrict it to just characters that actually have some letter nature to them, but the trouble with that is it'd make the backend lexical rules encoding-dependent, which is bad news for a number of reasons. So we allow 200-377 in all cases. regards, tom lane