Tom Lane <t...@sss.pgh.pa.us> wrote: > "Kevin Grittner" <kevin.gritt...@wicourts.gov> writes: >> Tom Lane <t...@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
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
