Re: [PATCH] explain sortorder
От | Mike Blackwell |
---|---|
Тема | Re: [PATCH] explain sortorder |
Дата | |
Msg-id | CANPAkgtF-YLKo_u1XxYX8gSvhzHmC4uD8au-V4iu7-xO+zAxjg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [PATCH] explain sortorder (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
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.Blackwell@rrd.com
http://www.rrdonnelley.com
On Mon, Jan 19, 2015 at 10:09 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
"Timmer, Marius" <marius.timmer@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
В списке pgsql-hackers по дате отправления: