Re: BUG #18051: char(N) and varchar(N) behave opposite to the documentation - Mailing list pgsql-bugs

From David Rowley
Subject Re: BUG #18051: char(N) and varchar(N) behave opposite to the documentation
Date
Msg-id CAApHDvppj5iWgsbnqQdVEG=HqOGhfkoEWELXxJ=S74qnmPL--A@mail.gmail.com
Whole thread Raw
In response to Re: BUG #18051: char(N) and varchar(N) behave opposite to the documentation  (Nicolas Gouteux <nicolas.gouteux@sonarsource.com>)
Responses Re: BUG #18051: char(N) and varchar(N) behave opposite to the documentation
List pgsql-bugs
On Thu, 10 Aug 2023 at 02:47, Nicolas Gouteux
<nicolas.gouteux@sonarsource.com> wrote:
> I don't have any issue with this discrepancy with other vendors, but I believe it's good to know (and maybe advertise
inthe docs?
 

Maybe it's worth noting it down in [1] in char_length and length.

Looking at [2], it does not look like they were able to glean much
guidance from the SQL standard on this.  It's late here, but it seems
to me that if it was left as it was, then the user could have had a
choice by using length(rtrim(col)), but if we strip them out and the
user wants to get the full padded width, it's much harder to do maybe
with pg_column_size() and some insider knowledge on when we use 1-byte
headers and when we use 4-byte headers.

Anyway, 2004 was a long time ago. I can't imagine we could possibly
make such a change today to put it back.  We might even struggle if
the SQL standard was more clear on it (I've not looked again to check
if there've been improvements from what was found in 2004).

David

[1] https://www.postgresql.org/docs/current/functions-string.html
[2] https://www.postgresql.org/message-id/Pine.LNX.4.58.0401271806250.22203%40linuxworld.com.au



pgsql-bugs by date:

Previous
From: Félix GERZAGUET
Date:
Subject: Re: BUG #18051: char(N) and varchar(N) behave opposite to the documentation
Next
From: Tom Lane
Date:
Subject: Re: BUG #18051: char(N) and varchar(N) behave opposite to the documentation