On Fri, Aug 16, 2013 at 8:37 PM, BladeOfLight16
<bladeoflight16@xxxxxxxxx> wrote:
> On Wed, Aug 14, 2013 at 2:56 PM, Tom Lane <tgl@xxxxxxxxxxxxx> wrote:
>>
>> Our interpretation is that a bare column name ("ORDER BY foo") is resolved
>> first as an output-column label, or failing that as an input-column name.
>> However, as soon as you embed a name in an expression, it will be treated
>> *only* as an input column name.
>>
>> The SQL standard is not a lot of help here. In SQL92, the only allowed
>> forms of ORDER BY arguments were an output column name or an output column
>> number. SQL99 and later dropped that definition (acknowledging that they
>> were being incompatible) and substituted some fairly impenetrable verbiage
>> that seems to boil down to allowing input column names that can be within
>> expressions. At least that's how we've chosen to read it. Our current
>> behavior is a compromise that tries to support both editions of the spec.
>
>
> Asking as a comparative know-nothing who would like to be more informed, is
> there something wrong with the notion of throwing an error that m in the
> ORDER BY clause is ambiguous here? As near as I can tell, it really is
> ambiguous as long as both input or output columns are accepted, so either
> way is essentially a total guess about what the user wants. It seems to me
> that throwing an error would be the most intuitive and clearly defined way
> of handling this case.
Well it's not likely that the current behaviour will be changed since
there are likely apps that rely on it working (sort of) the way it is.
A warning or notice might make sense then.
--
To understand recursion, one must first understand recursion.
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
