Re: sortsupport for text
| От | Peter Geoghegan |
|---|---|
| Тема | Re: sortsupport for text |
| Дата | |
| Msg-id | CAEYLb_X3AF8t2pEq2RaYQer5ywSVprkkoq=06HEqUiYpWsEveA@mail.gmail.com обсуждение исходный текст |
| Ответ на | sortsupport for text (Robert Haas <robertmhaas@gmail.com>) |
| Ответы |
Re: sortsupport for text
|
| Список | pgsql-hackers |
<p><br /> On Jun 17, 2012 5:50 PM, "Tom Lane" <<a href="mailto:tgl@sss.pgh.pa.us">tgl@sss.pgh.pa.us</a>> wrote:<br/> ><br /> > Peter Geoghegan <<a href="mailto:peter@2ndquadrant.com">peter@2ndquadrant.com</a>> writes:<br/> > > On 17 June 2012 17:01, Tom Lane <<a href="mailto:tgl@sss.pgh.pa.us">tgl@sss.pgh.pa.us</a>> wrote:<br/> > How exactly do you plan to shoehorn that into SQL? You could invent<br /> > some nonstandard "equivalence"operator I suppose, but what will be the<br /> > value? We aren't going to set things up in such a way thatwe can't<br /> > use hash join or hash aggregation in queries that use the regular "="<br /> > operator.<p>Right,most people won't care. You may or may not want a new <br /> Operator for equivalency. The regular operatorfor equality doesn't have to and shouldn't change. It is both useful and conceptually clean to not guarantee thata compator can be relied upon to indicate equality and not just equivalency.
В списке pgsql-hackers по дате отправления: