Re: Prepare/Execute silently discards prohibited ORDER BY values

From: Pedro Gimeno <pgsql-004(at)personal(dot)formauri(dot)es>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Josh Berkus <josh(at)agliodbs(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: Prepare/Execute silently discards prohibited ORDER BY values
Date: 2015-05-14 12:38:52
Message-ID: 5554975C.9060608@personal.formauri.es
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Tom Lane wrote, On 2015-05-14 03:05:
> Agreed; I think the reason why we disallow this case is not so much
> string literals as numeric literals. It would be an even bigger POLA
> violation if "ORDER BY 1" and "ORDER BY 1.0" were both accepted and did
> fundamentally different things.

If that helps, I don't think of that as violating the POLA
significantly. This is IMO a much worse violation:

=$ WITH test AS (SELECT 1 UNION ALL SELECT 0) SELECT * FROM test ORDER BY 1;
?column?
----------
0
1
(2 rows)

=$ WITH test AS (SELECT 1 UNION ALL SELECT 0) SELECT * FROM test ORDER
BY 1::integer;
?column?
----------
1
0
(2 rows)

especially since the latter ORDER BY clause is more likely to be the
result of a dumb automatic query generator that appends types to every
expression. But I, as an user, understand and accept that appending a
type changes the meaning of the ORDER BY.

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message udtelco 2015-05-14 17:12:53 BUG #13289: ANY() function produces a paradox
Previous Message Hillel.Eilat 2015-05-14 10:55:14 BUG #13287: Database corruption - PANIC: could not fsync file "pg_replslot/[Slot]/state": Bad file descriptor