X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.2]) by svr1.postgresql.org (Postfix) with ESMTP id 5E992D1B4C0 for ; Mon, 16 Feb 2004 03:47:36 +0000 (GMT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (neptune.hub.org [200.46.204.2]) (amavisd-new, port 10024) with ESMTP id 76888-08 for ; Sun, 15 Feb 2004 23:47:34 -0400 (AST) Received: from news.hub.org (news.hub.org [200.46.204.72]) by svr1.postgresql.org (Postfix) with ESMTP id F0AA3D1D27F for ; Sun, 15 Feb 2004 23:47:29 -0400 (AST) Received: from news.hub.org (news.hub.org [200.46.204.72]) by news.hub.org (8.12.9/8.12.9) with ESMTP id i1G3l81Y021232 for ; Mon, 16 Feb 2004 03:47:13 GMT (envelope-from news@news.hub.org) Received: (from news@localhost) by news.hub.org (8.12.9/8.12.9/Submit) id i1G3TOku018188 for pgsql-sql@postgresql.org; Mon, 16 Feb 2004 03:29:24 GMT From: "news.postgresql.org" X-Newsgroups: comp.databases.postgresql.sql Subject: CHAR(n) always trims trailing spaces in 7.4 Date: Mon, 16 Feb 2004 11:29:42 +0800 Organization: Hub.Org Networking Services Lines: 50 Message-ID: References: <20040212000610.13913.qmail@web60806.mail.yahoo.com> X-Complaints-To: usenet@news.hub.org X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 To: pgsql-sql@postgresql.org X-Virus-Scanned: by amavisd-new at postgresql.org X-Archive-Number: 200402/218 X-Sequence-Number: 16908 Hello, I just discovered the following change to CHAR(n) (taken from varlena.com, general bits, issue 62). This will cause me serious heart-ache, back-ache and bug-ache if we upgrade to 7.4. Is there any compatibility flag available to use pre-7.4 behaviour for CHAR(n)? Regards, John ================== In 7.4, one of the changes was that the char(n) type now truncates trailing spaces. This causes a problem for those of us using ::char(n) to create fixed length fields. Creating fixed length field batch files are usually required to interface with legacy systems. In the example below, psql is called from a shell with tuples only (t) and unaligned (A). The result of the selection creates a fixed width file. One of the techniques used to create fixed length fields in 7.3 and earlier was to cast the value to char(n). This along with the various to_char() functions used to be able to create fixed length records. For example: % psql -At > batch.out << END select accountid::char(30), to_char( transaction_amount, 'FM000.00'), (lastname || ',' || firstname )::char(40), bankid::char(15), to_char( now(), 'YYYYMMDD'); END In 7.4 this no longer works. The fields created with the cast are no longer fixed length. Instead of using the cast to make fixed length fields, use rpad() and lpad() to do the same thing. rpad(string text, length integer [, fill text]) lpad(string text, length integer [, fill text]) The previous selection should now be written as follows. % psql -At > batch.out << END select rpad(accountid,30), to_char( transaction_amount, 'FM000.00'), rpad( (lastname || ',' || firstname ), 40), rpad(bankid, 15), to_char( now(), 'YYYYMMDD'); END