On Wed, Sep 6, 2017 at 7:10 PM, Артём Костин <kostin.artem@gmail.com> wrote:
> I'm sorry for this approach.
If it is for the top-quoting approach, just correct it.
> The main point is that behaviour are not applied to all character types
> described in docs. You can see it in my example.
It may, but that's not what we were discussing. Or may be. As I said,
your quoting style makes it extremely difficult to know what we are
replying to.
> For the second point, please, check chapter 8.3 for this
> "Trailing spaces are removed when converting a character value to one of the
> other string types. Note that trailing spaces are semantically significant
> in character varying and text values, and when using pattern matching, that
> is LIKE and regular expressions."
> According to the last sentence I expect spaces after characters. It would be
> strange first convert character to string and when string to text type,
> don't you think so?
It may, but as TL said the functions ( and operators, which are just
syntatic sugar for a function call ) work on text. You may interpreted
the sentence as "substring and concatenation do not convert as they
are not enumerated there". But, OTOH, char(n) fields work as people
caoming from punched cards and fixed lentght records are used to. In
this time you had to space-pad ( among other things space was
no-punch, no print, so you saved ink and increased structural
integrity by space-padding instead of usaing any other char ) and
every operation right-trimmed before aplying, as you had no var-length
fields.
This is why, when we got access to var-length fields, used them
everywhere to avoid this kind of surprises. I've been avoiding fixed
char fields since I can remember.
FOS
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs