Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
>> Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> It would be way nicer if we could strip trailing blanks on
>>> storage, and then figure a way to either reconstitute them on
>>> output
>
>> How about pushing it even farther back -- always keep them with
>> trimmed trailing spaces and add trailing spaces as required in
>> operator functions?
>
> I think that's what I said. AFAIK there isn't any place where we'd
> need to add back the spaces except the output function. All the
> operators would be just as happy if the spaces weren't there.
Sorry, I misread it.
If this can be done, it might ease the transition from other products
for some people. In Sybase there were significant performance
benefits to using char() instead of varchar() in certain
circumstances. In our first test conversion from Sybase we mapped all
domains and columns which were char(n) in Sybase to the same in
PostgreSQL, which caused some pain. It was no big deal to remap those
to varchar() and re-run, but on the face of it, it seems like there
wouldn't be a significant performance hit for char() with this change,
so it would be one less thing for people to stub their toes on during
migration.
-Kevin
