Re: Windowing Function Patch Review -> Standard Conformance

From: "David Rowley" <dgrowley(at)gmail(dot)com>
To: "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "'Hitoshi Harada'" <umi(dot)tanuki(at)gmail(dot)com>, "'PostgreSQL-development'" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Windowing Function Patch Review -> Standard Conformance
Date: 2008-12-29 23:32:33
Message-ID: 0E8DD1BFEC6A4452A0518325498D66D5@amd64
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane Wrote:
> Actually, it's not ambiguous according to our interpretation of ORDER BY
> clauses: the first attempt is to match an output column name, so it's
> seizing on the first SELECT column (b.parentpart) as being the intended
> sort key for "parentpart", and similarly for "childpart". You'd get the
> same thing if you did "ORDER BY 1,2".
>

Aha, I see. Well I learned something new tonight. I didn't realise that
Postgres would be that intelligent about it. It makes total sense. I
probably should have known this, but I'll forgive myself as I'm one of these
people that will prefix all column names when joining in case I ever add new
conflicting columns. <end of excuse>

> We could disable all those special rules for window cases, but then we'd
> have to document how window ORDER BY is different from query ORDER BY,
> etc. I think it'd be more confusing not less so.
>

Without any further thought, I vote to leave it how it is.

David.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2008-12-29 23:42:00 parallel restore
Previous Message Magnus Hagander 2008-12-29 23:25:17 Re: new libpq SSL connection option