Re: [PATCH] explain sortorder

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(dot)Blackwell(at)rrd(dot)com
http://www.rrdonnelley.com

<http://www.rrdonnelley.com/>
* <Mike(dot)Blackwell(at)rrd(dot)com>*

On Mon, Jan 19, 2015 at 10:09 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> "Timmer, Marius" <marius(dot)timmer(at)uni-muenster(dot)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(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>