From: | Jordan Lewis <jordanthelewis(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: ORDER BY $1 behaves inconsistently |
Date: | 2017-10-27 21:05:26 |
Message-ID: | CAALgziJKJgU=UP7FSfyLvHGKEJ2O=zjYCoLVUcJnTu+7rkD_SA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Thanks for the explanation - that makes sense.
On Fri, Oct 27, 2017 at 2:33 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Jordan Lewis <jordanthelewis(at)gmail(dot)com> writes:
> > Actually, it's even worse than I thought. It seems that placeholders in
> > ORDER BY clauses get entirely ignored,
> > as running `EXECUTE x(1)` on the previous example with unsorted table
> data
> > does not sort the table by the 1st
> > column as expected.
>
> "ORDER BY $1" is asking to order by some constant value (constant within
> any one execution of the command, anyway), which is useless, because all
> rows in the query will have the same sort key. The planner will throw
> that away as being a no-op.
>
> "ORDER BY 1" is asking to order by the first output column. This is
> not the same thing. You cannot get that effect with a parameter;
> if you could, it would probably represent a SQL-injection hazard.
>
> If the value of $1 were "foo" and you complained that it didn't order
> by column foo, it would be exactly the same issue...
>
> regards, tom lane
>
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2017-10-27 23:01:28 | Re: BUG #14874: Dublicate values in primary key |
Previous Message | Cristiano Coelho | 2017-10-27 18:48:08 | pg_trgm word_similarity inconsistencies or bug |