Tom, Thanks for the comments on what you ended up changing. It helps point out the kind of things I should be looking for. I'll try to let less slip through in the future.
Mike __________________________________________________________________________________ *Mike Blackwell | Technical Analyst, Distribution Services/Rollout Management | RR Donnelley* 1750 Wallace Ave | St Charles, IL 60174-3401 Office: 630.313.7818 mike.blackw...@rrd.com http://www.rrdonnelley.com <http://www.rrdonnelley.com/> * <mike.blackw...@rrd.com>* On Mon, Jan 19, 2015 at 10:09 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > "Timmer, Marius" <marius.tim...@uni-muenster.de> writes: > > We think, you wanted to switch to DESC behavior > > (print out NULLS FIRST) in cases, where > > „USING“ uses an operator which is considered to be > > a DESC operator. > > Right, because that's how addTargetToSortList() would parse it. > > > But get_equality_op_for_ordering_op is called in > > cases, where reverse is false, but > > the part > > if (reverse) > > *reverse = (strategy == BTGreaterStrategyNumber); > > never changes this to true? > > Sorry, not following? It's true that what I added to explain.c doesn't > worry too much about the possibility of get_ordering_op_properties() > failing --- that really shouldn't happen for something that was previously > accepted as a sorting operator. But if it does, "reverse" will just be > left as false, so the behavior will anyway be unsurprising I think. > We could alternatively make it throw a "cache lookup failed" error but > I'm not sure how that makes anyone's life better. > > regards, tom lane > > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers >
