Re: Prepare/Execute silently discards prohibited ORDER BY values - Mailing list pgsql-bugs

From Pedro Gimeno
Subject Re: Prepare/Execute silently discards prohibited ORDER BY values
Date
Msg-id 5554975C.9060608@personal.formauri.es
Whole thread Raw
In response to Re: Prepare/Execute silently discards prohibited ORDER BY values  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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.

pgsql-bugs by date:

Previous
From: Hillel.Eilat@attunity.com
Date:
Subject: BUG #13287: Database corruption - PANIC: could not fsync file "pg_replslot/[Slot]/state": Bad file descriptor
Next
From: Andres Freund
Date:
Subject: Re: BUG #13287: Database corruption - PANIC: could not fsync file "pg_replslot/[Slot]/state": Bad file descriptor