| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> | 
|---|---|
| To: | "Timmer, Marius" <marius(dot)timmer(at)uni-muenster(dot)de> | 
| Cc: | Arne Scheffer <scheffa(at)uni-muenster(dot)de>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, pgsql-hackerspostgresqlorg <pgsql-hackers(at)postgresql(dot)org> | 
| Subject: | Re: [PATCH] explain sortorder | 
| Date: | 2015-01-19 16:09:34 | 
| Message-ID: | 27093.1421683774@sss.pgh.pa.us | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
"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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pavel Stehule | 2015-01-19 16:14:05 | Re: proposal: disallow operator "=>" and use it for named parameters | 
| Previous Message | Stephen Frost | 2015-01-19 16:05:22 | Re: WITH CHECK and Column-Level Privileges |