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.
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 |