From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | elein <elein(at)varlena(dot)com> |
Cc: | "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com>, "news(dot)postgresql(dot)org" <jlim(at)natsoft(dot)com(dot)my>, pgsql-sql(at)postgresql(dot)org |
Subject: | Re: CHAR(n) always trims trailing spaces in 7.4 |
Date: | 2004-02-19 04:58:37 |
Message-ID: | 28866.1077166717@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-sql |
elein <elein(at)varlena(dot)com> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-02-19 05:01:26 | Re: unqualified function calls in system_views.sql |
Previous Message | Christopher Kings-Lynne | 2004-02-19 04:16:13 | unqualified function calls in system_views.sql |
From | Date | Subject | |
---|---|---|---|
Next Message | Rodrigo Sakai | 2004-02-19 12:44:12 | Compiling pl/pgsql functions |
Previous Message | Josh Berkus | 2004-02-19 04:39:13 | Re: Distributed Transactions |