| 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: | Whole Thread | Raw Message | 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 |