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

Re: [TF-LIB] IN operator

From: Ivan Mikhailov <imikhailov@openlinksw.com>
Date: Mon, 08 Feb 2010 23:40:47 +0600
To: Steve Harris <steve.harris@garlik.com>
Cc: Andy Seaborne <andy.seaborne@talis.com>, SPARQL Working Group <public-rdf-dawg@w3.org>
Message-Id: <1265650847.17678.6850.camel@octo.iv.dev.null>
> >>> If both scalar subqueries and IN are supported then
> >>> ?expn IN (SELECT...)
> >>> should also be supported, of course.
> >>
> >> That's a bit of a leap, and I don't think I agree.
> >
> > Fine. The simpler the better. From my perspective, it's not a  
> > problem if
> > a feature is not in spec even if we've implemented it already. A  
> > problem
> > might appear only if a feature is made by two vendors in two different
> > ways.
> 
> The only major contentious issues I could see would be the number of  
> columns projected (SQL only allows one right?) and whether there's {}s  
> or not.

To {} or not to {}. I don't care, I can agree with {} (but I don't like
it). The parser will tolerate any variant, or even union of them: IN
(SELECT), IN ({SELECT}), IN ((SELECT))...

Re. number of columns --- I'd personally agree with any, if others
decide so, even if I don't see a big practical need. Our SQL is extended
with a BREAKUP that turns short and wide result set into long and
narrow. BREAKUP syntax is
SELECT BREAKUP (result-set-1) (result-set-2)...(result-set-N)
FROM <typical_rest_of_select_here>
it is calculated as usual SELECT but returns N rows instead of one per
every result of FROM join or uinon or whatever. Multiple columns there
will cost us a little.

Moreover, our procedure views let us to make something I would name
"disaggregate functions", e.g. conversion result-set of vectors into
result-set of all elements of these vectors.

Ivan.
Received on Monday, 8 February 2010 17:41:23 GMT

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