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 (AT) agliodbs (DOT) com www.agliodbs.com
Ph: 415-752-2500 Fax: 415-752-2387
2166 Hayes Suite 200 San Francisco, CA

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Folks,

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 (AT) agliodbs (DOT) com www.agliodbs.com
Ph: 415-752-2500 Fax: 415-752-2387
2166 Hayes Suite 200 San Francisco, CA

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

Josh Berkus <josh (AT) agliodbs (DOT) com> writes:
[ 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

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Josh Berkus <josh (AT) agliodbs (DOT) com> writes:
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

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org