Re: BUG #14800: substring produces different results with similar types

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.

In response to

Browse pgsql-bugs by date

  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