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 6761BD1B4C5 for ; Thu, 19 Feb 2004 18:58:34 +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 73196-10 for ; Thu, 19 Feb 2004 14:58:33 -0400 (AST) Received: from cookie.varlena.com (adsl-64-142-36-103.sonic.net [64.142.36.103]) by svr1.postgresql.org (Postfix) with ESMTP id 66C5FD1B456 for ; Thu, 19 Feb 2004 14:58:32 -0400 (AST) Received: by cookie.varlena.com (Postfix on SuSE Linux 7.3 (i386), from userid 500) id D3CD138C85; Thu, 19 Feb 2004 10:55:05 -0800 (PST) Date: Thu, 19 Feb 2004 10:55:05 -0800 From: elein To: Tom Lane Cc: elein , "scott.marlowe" , "news.postgresql.org" , pgsql-sql@postgresql.org Subject: Re: CHAR(n) always trims trailing spaces in 7.4 Message-ID: <20040219105505.S25537@cookie.varlena.com> Mail-Followup-To: Tom Lane , "scott.marlowe" , "news.postgresql.org" , pgsql-sql@postgresql.org References: <18872.1077061249@sss.pgh.pa.us> <20040217162713.H25537@cookie.varlena.com> <20170.1077076397@sss.pgh.pa.us> <20040218120547.J25537@cookie.varlena.com> <28866.1077166717@sss.pgh.pa.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <28866.1077166717@sss.pgh.pa.us> User-Agent: Mutt/1.3.22.1i X-Virus-Scanned: by amavisd-new at postgresql.org X-Archive-Number: 200402/281 X-Sequence-Number: 16971 I guess I am asking about the cast sequence from char(n) to text. (' '::char(n))::text trims spaces. This is wrong, imo. ' '::text does not trim spaces. ' '::char(n) does not trim spaces and pads. char(n) should not trim spaces, right? And it doesn't on an insert. Text does not trim spaces. Somewhere the space trimming occurs. If it is in the operator || then the operator is wrong. If char(n) is properly defined to not trim spaces then there should be a separate cat for char(n). It is correct for it to behave differently than cat for text and varchar because of the different trimming behaviour. I can do this patch if there is agreement. But I may not be able to do it immediately. elein On Wed, Feb 18, 2004 at 11:58:37PM -0500, Tom Lane wrote: > elein writes: > > So exactly what is the order of casts that produces > > different results with: > > > 'x' || ' ' || 'x' and 'x' || ' '::char15 || 'x' > > > Are operators being invoked both (text,text)? > > The only relevant operator is "text || text" (there are also some || > operators for arrays, bytea, and BIT, but these will all be discarded > as not the most plausible match). Therefore, in your first example the > unspecified literals will all be presumed to be text, so the space does > not get trimmed. > > One of the things we could think about as a way to tweak the behavior is > creating "||" variants that are declared to accept char(n) on one or > both sides. These could actually use the same C implementation function > (textcat) of course. But declaring them that way would suppress the > invocation of rtrim() as char-to-text conversion. > > However, if we did that then "||" would behave differently from other > operators on character strings, so it doesn't seem like a very > attractive option to me. > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 9: the planner will ignore your desire to choose an index scan if your > joining column's datatypes do not match