"Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at> writes:
> One alternate possible approach would maybe be to change the on-disk
> representation to really be binary compatible and change the input
> output and operator functions ?
Hmm ... now that's an interesting thought. So the input converter would
actively strip trailing blanks, output would add them back, and only in
a few char(n)-specific functions would we need to pretend they are there.
This would mean that char(n)-to-text is binary compatible but the
reverse direction is not (it must strip trailing blanks) --- but that
coercion could be folded into the existing length-limit checker for
char(n) columns.
> IIRC fixed width optimizations do not gain as
> much as in earlier versions anyway.
There are no fixed-width optimizations for char(n) at all, now that we
have multibyte enabled all the time.
Seems like a great idea to me.
regards, tom lane
