Re: How are null's stored?
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Stephan Szabo <sszabo@megazone23.bigpanda.com>
Cc: Josh Berkus <josh@agliodbs.com>, Ryan <pgsql-performance@seahat.com>, pgsql-performance@postgresql.org
Date: 2003-05-12T23:50:24Z
Lists: pgsql-hackers, pgsql-performance
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