At 11:46 7/08/00 -0400, Tom Lane wrote:
>Philip Warner <pjw@rhyme.com.au> writes:
>> Just wondering why subselect expressions can not have a limit/order clause,
>
>We could ignore the spec and implement this as an extension, but I'd
>want to see some fairly compelling arguments why it's a good idea.
>(In other words, why do you know better than the designers of SQL?)
Well, it's not *just* me. Both Dec/RDB and SQL/Server implement ORDER BY in
subqueries. SQL/Server insists on a limit statement in this case, whereas
Dec/Rdb just dies if more than one row is returned.
It is a very useful thing when you are scanning though sequential records
that are time based, or have ID's that have 'holes' in the sequence. eg. in
the case of time-based data, you can derive durations.
But it can be done by writing a plpgsql function, so it's not a big issue.
>> It can obviously be done in two select statements, but I was just wondering
>> if it's an oversight or a planner problem?
>
>I'd say mostly an executor problem, actually. Nobody's figured out
>where the executor would need to be hacked to support tuple-limits
>applied elsewhere than the top level of a select.
Wouldn't is also have a fair impact on the planner? Or does it always
assume that subselects only return one row?
----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.C.N. 008 659 498) | /(@) ______---_
Tel: (+61) 0500 83 82 81 | _________ \
Fax: (+61) 0500 83 82 82 | ___________ |
Http://www.rhyme.com.au | / \| | --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/
