From: | Francisco Olarte <folarte(at)peoplecall(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | kostin(dot)artem(at)gmail(dot)com, "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: BUG #14800: substring produces different results with similar types |
Date: | 2017-09-06 16:43:34 |
Message-ID: | CA+bJJbygqhGsFqPG7sf4wmk3fn6D00GsD5dFpuFithLeMo-M8Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Tom:
On Wed, Sep 6, 2017 at 4:51 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Francisco Olarte <folarte(at)peoplecall(dot)com> writes:
>> Anyway, you may notice char() discards trailing blanks, varchar does not:
> More precisely, converting from char(n) to varchar or text discards
> trailing blanks. Since both substring() and the || operator take
> text argument types, an implicit coercion to text is happening in
> these examples ... and that's where the blanks went.
I was suspecting that, but
https://www.postgresql.org/docs/9.6/static/functions-string.html
documents them as "string || string", returns text, and
"substring(string {several variants})", returns text and trying to
look where the conversion to text happened ( i.e., in the arguments,
or after aplying overloaded variants ) seemed a bit extreme. Not
surprising, anyway, of the space chopping, having worked with punched
cards I'm used to it.
From | Date | Subject | |
---|---|---|---|
Next Message | Francisco Olarte | 2017-09-06 16:45:44 | Re: BUG #14800: substring produces different results with similar types |
Previous Message | davidr | 2017-09-06 16:12:12 | BUG #14801: ECPG core dump |