[Mulgara-dev] iTQL features

[David Wood]

On 2 Nov2006, at 12:02, Paul Gearon wrote:
> A conversation with Andrae has him disagreeing.

Yes, that would be because Andrae always thinks through the  
ramifications.  Well done, Andrae.

> He's fine with the feature, but not with the iTQL syntax.

Well, "it's just syntax", right?  Is Andrae's argument based on  
difficulties with Sable-CC or solely with the code aesthetic of  
duplicating variables in SELECT?

> I'll let him write the details of his own opinion, but in essence  
> he believes that insert-select is a hack.  It is entirely for this  
> construction that duplicates of variables in a select clause are  
> allowed.  It is also the reason for permitting constants in the  
> select clause.

It is a hack (even in SQL, AFAIK), but it is a common and useful hack.

It should be noted that INSERT-SELECT is our currently published  
workaround for at least one bug relating to backups, although I don't  
recall which one.  Maybe it was per-model backups, which was a  
feature lost in the migration from NGC-sponsored Kowari, right?

> Extending "select" in this way, entirely so it can be used for  
> "insert-select" is not a good reason to go tainting processing the  
> standard "select" query.

I can see that.

> He would rather see a SPARQL-esque "insert-construct".
...
> This approach makes sense to me, with one caveat.  iTQL was  
> designed to look as SQL-like as possible.  "Insert-select" came  
> about because of that approach.  This will be moving away from that  
> explicit design decision.

The reason for the original SQL-like design decision (mine, as I  
recall) was because we didn't have any potential users who knew iTQL  
and a lot of people knew SQL.  RDF query languages were both niche  
and used by very few people.  We hoped that SQL-like syntax would  
help new users get comfortable with an RDF database.

I believe that we are past that point now.  Our benchmark for  
deviations should now be SPARQL, not SQL.

So, I would support some form of special insert contruct (with the  
recognition that SPARQL does not currently have such a construct in  
any form).

> Fortunately the change is not that difficult, and only  
> significantly affects the syntax.  The change to processing would  
> be minor.  Whatever people think, it will only get changed by  
> someone who cares about it enough.  For the moment, the only person  
> I know of who really wants this syntax change is Andrae, and I know  
> that he's too busy working on transactions to make it happen.  :-)

Heh.  Now we get to the meat of the issue.

Regards,
Dave