Re: BUG #18051: char(N) and varchar(N) behave opposite to the documentation

From: Félix GERZAGUET <felix(dot)gerzaguet(at)gmail(dot)com>
To: Nicolas Gouteux <nicolas(dot)gouteux(at)sonarsource(dot)com>
Cc: David Rowley <dgrowleyml(at)gmail(dot)com>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: BUG #18051: char(N) and varchar(N) behave opposite to the documentation
Date: 2023-08-09 15:02:26
Message-ID: CANVwZtvyiT3Vz-RB8V-nvzt4tjZ-C8ucaBpVZ77w5v_xMOFTVA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Hello Nicolas,

On Wed, Aug 9, 2023 at 4:47 PM Nicolas Gouteux <
nicolas(dot)gouteux(at)sonarsource(dot)com> wrote:

> I was just trying to show more junior programmers the difference between
> the 'assumed' padded char and the more modern 'trimming' varchar
> So imagine my surprise when both length() and concatenation() yielded the
> exactly opposite behavior than expected!
>

For such pedagogic purpose you can use:

select length(cast('A' as char(4))::bytea)

But you then have to explain the ::bytea trick :-)

Best Regards,

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message David Rowley 2023-08-09 15:03:19 Re: BUG #18051: char(N) and varchar(N) behave opposite to the documentation
Previous Message Nicolas Gouteux 2023-08-09 14:49:17 Re: BUG #18051: char(N) and varchar(N) behave opposite to the documentation