Re: How are null's stored?
От | Tom Lane |
---|---|
Тема | Re: How are null's stored? |
Дата | |
Msg-id | 28558.1052856970@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: How are null's stored? (Stephan Szabo <sszabo@megazone23.bigpanda.com>) |
Список | pgsql-performance |
Stephan Szabo <sszabo@megazone23.bigpanda.com> writes: > On Mon, 12 May 2003, Tom Lane wrote: >> 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). > This seems to possibly work on 7.4. I took my system and removed the > varchar comparison operators and directly made a text_ops index on a > varchar(30). Yeah, I fooled with it a little bit last night too. It seems that we'd need to still have a varchar_ops entry in pg_opclass (else you get complaints about unable to select a default opclass, not to mention that old pg_dump files specifying varchar_ops would fail to load). But this entry could point to the textual comparison operators. AFAICT the planner doesn't have any problem dealing with the implicit coercions that it's faced with in such cases. >> 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 guess this depends on how we read the comparisons/conversions from PAD > SPACE to NO PAD are supposed to work, but I think this would be good and > make things easier for alot of people since most people don't expect it, > especially when using functions like upper and lower that return text. I tried that too, and it seemed to work as expected. Whether it's arguably more spec-compliant than our current behavior I dunno; haven't looked at that part of the spec closely... regards, tom lane
В списке pgsql-performance по дате отправления: