W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > July to September 2010

Re: limit per resource rethought...

From: Steve Harris <steve.harris@garlik.com>
Date: Fri, 13 Aug 2010 11:29:33 +0100
Cc: SPARQL Working Group <public-rdf-dawg@w3.org>, Andy Seaborne <andy.seaborne@epimorphics.com>, Paul Gearon <gearon@ieee.org>
Message-Id: <888AAE5E-C39B-41EF-A3E6-B9EBF4C4F2B1@garlik.com>
To: Axel Polleres <axel.polleres@deri.org>
On 2010-08-13, at 10:21, Axel Polleres wrote:

>> SELECT A,B FROM KNOWS k1 WHERE B IN (SELECT B FROM KNOWS k2 WHERE k1.A=k2.A LIMIT n);
> 
> Just adding a few notes here: 
> 1)  LIMIT is actually not standard in SQL

That's true, but it's rather widely implemented. I think MS SQL was the last to hold out, and they added it recently.

>  http://en.wikipedia.org/wiki/Select_%28SQL%29#Limiting_result_rows
> in ISO SQL:2008 FETCH FIRST should work...

That's just a standard way to write LIMIT, it doesn't alter the execution model.

> 2) this SQL version using IN here, actually rather amounts to allowing IN along with unary SELECTs in FILTERs for us... 
>   which would reopen ISSUE-6 in which case the query would probably look be something like:
> 
>   SELECT ?A ?B WHERE { ?A :knows ?B FILTER ( ?B IN ( SELECT ?B1 WHERE {?A :knows ?B1} LIMIT n ) ) }
> 
> BTW, I acknowledge of course that this whole use case is kind of complementary to the original LIMIT per resource [1] use case

And you still won't get the behaviour you'd like, it's evaluated bottom-up. See my other mail.

- Steve

-- 
Steve Harris, CTO, Garlik Limited
1-3 Halford Road, Richmond, TW10 6AW, UK
+44 20 8439 8203  http://www.garlik.com/
Registered in England and Wales 535 7233 VAT # 849 0517 11
Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10 9AD
Received on Friday, 13 August 2010 10:30:09 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:43 GMT