Implicit type conversion -- where documented?
I came across what seems like anomalous behavior regarding
implicit conversion from a numeric type to text. You can write:
select 3.1416 || '?';
and the number implicitly converts to text and concatenates just fine, but
writing:
select trim(3.1416);
fails with an error message. This seems odd to me--in both cases a float
literal is used in a context expecting text; in one case it implicitly
converts, in the other it doesn't.
*This brings up my real question*: are the details of this documented
anywhere? Chapter 10 refers to ' implicit conversions' but I can't see
anywhere that the docs explain the details of how it is done, that would
explain the observed difference in behavior described above.
Thanks!
Hi,
On Thu, Nov 10, 2022 at 06:27:21PM -0800, Kirk Parker wrote:
I came across what seems like anomalous behavior regarding
implicit conversion from a numeric type to text. You can write:select 3.1416 || '?';
and the number implicitly converts to text and concatenates just fine, but
writing:select trim(3.1416);
fails with an error message. This seems odd to me--in both cases a float
literal is used in a context expecting text; in one case it implicitly
converts, in the other it doesn't.*This brings up my real question*: are the details of this documented
anywhere? Chapter 10 refers to ' implicit conversions' but I can't see
anywhere that the docs explain the details of how it is done, that would
explain the observed difference in behavior described above.
There are actually no cast defined from numeric to text, so you won't find a
documentation for that.
The first example is working as documented at
https://www.postgresql.org/docs/current/functions-string.html:
anynonarray || text → text
Converts the non-string input to text, then concatenates the two strings. (The
non-string input cannot be of an array type, because that would create
ambiguity with the array || operators. If you want to concatenate an array's
text equivalent, cast it to text explicitly.)