- 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>
> >>> 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 UTC