| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
| Cc: | Nicolas Gouteux <nicolas(dot)gouteux(at)sonarsource(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:26:12 |
| Message-ID: | 101253.1691594772@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
David Rowley <dgrowleyml(at)gmail(dot)com> writes:
> Anyway, 2004 was a long time ago. I can't imagine we could possibly
> make such a change today to put it back.
Yeah. IMV, char(N) is a legacy type with legacy behaviors, and
we shouldn't change those behaviors for fear of breaking legacy
applications that might expect them. If you don't like the way it
works, don't use char(N).
BTW, as far as the question of better optimization of fixed-width
fields goes, we couldn't do that anyway with char(N) except in the
ever-more-minority case of single-byte database encoding. That's
because N is counted in characters not bytes (as is quite clear
from the SQL standard, even if their opinion about trailing spaces
is less clear). I think that's a primary reason why nobody has
bothered to pursue such an optimization, and in turn that's why
char(N) is now such a backwater.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jacob Champion | 2023-08-09 23:10:39 | Re: pg_dump needs SELECT privileges on irrelevant extension table |
| Previous Message | David Rowley | 2023-08-09 15:03:19 | Re: BUG #18051: char(N) and varchar(N) behave opposite to the documentation |