- From: Steve Harris <steve.harris@garlik.com>
- Date: Fri, 13 Aug 2010 11:29:33 +0100
- To: Axel Polleres <axel.polleres@deri.org>
- Cc: SPARQL Working Group <public-rdf-dawg@w3.org>, Andy Seaborne <andy.seaborne@epimorphics.com>, Paul Gearon <gearon@ieee.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 UTC