> On Oct 29, 2021, at 2:26 PM, David M. Calascibetta <david@calascibetta.com> wrote:
>
> OK. I have a work-around so I'm alright.
Glad to hear it.
> I agree, the behavior is nuts, and is inconsistent with every other RDBMS out there.
I haven't studied the behavior of char(n) on other RDBMS products. I'd be curious if the SQL spec says anything that
we'reviolating in this regard. If so, we should at least have a warning in the docs about that. (We already have a
warningabout how char(n) behaves, but nothing I see about the behavior being non-compliant.) But I'm wondering if
otherRDBMS products really differ in this regard? Are you perhaps thinking about how varchar(n) works?
> I was only reporting it to improve the product, but if you think this is appropriate behavior,
> I'm good with it.
I tend to think of char(n) as a misfeature and avoid using it. Based on your experience with other RDBMSs, would you
expectchar(n) and varchar(n) to behave the same or to behave differently? In postgres, they are different, and
varchar(n)would behave more like you seem to want.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
