Stephan Szabo <sszabo@megazone23.bigpanda.com> writes:
> All in all, I'm not sure what the semantic differences between a varchar
> with no length specified and a text are in PostgreSQL actually and if the
> whole thing could be simplified in some way that doesn't break backwards
> compatibility.
Yeah, I've been wondering about that too. A large part of the problem
is that varchar has its own set of operators, which the planner has no
right to assume behave exactly like the text ones ... but they do. It
might work to rip out the redundant varchar operators and allow indexes
on varchar to become truly textual indexes (ie, they'd be text_ops not
varchar_ops opclass). There might be a few tweaks needed to get the
planner to play nice with indexes that require implicit coercions, but
I think it could be made to work.
Another idea that has been rattling around is to stop treating bpchar as
binary-equivalent to text, and in fact to make bpchar-to-text promotion
go through rtrim() to eliminate padding spaces.
I think this stuff got put on hold because we haven't been able to come
up with a good solution for the comparable problems in the numeric
datatype hierarchy. But bpchar/varchar/text is a lot simpler problem,
and maybe could be solved with the tools we have in place already.
regards, tom lane
