PartiQL Comparing to [xxx]

[yliuuuu]

1. Comparison with SQL++
   • Asked by jojspieg@ on community.partiql.org

PartiQL is committed to complete SQL-92 backwards compatibility. Technically, this means that when a database that supports PartiQL is able to process a query that follows the SQL-92 syntax, the result is identical to SQL-92.
One case where PartiQL is SQL-compatible while SQL++ is not, is the treatment of subqueries. The original UCSD SQL++ work had let subqueries to introduce incompatibility with SQL.For example, the query

SELECT o.date,
           (SELECT c.name FROM customers c WHERE c.id = o.customer) AS cname
FROM orders o

has the same result with SQL-92 in PartiQL, while in SQL++ the cname is a bag of tuples (nested table) with attribute name.

Further elaboration on the answer would also depend on whether you refer to the UCSD Configurable SQL++, which was a configurable metalanguage describing a family of languages, or a particular configuration, such as the Couchbase SQL++.

Answered by yannip@ on community.partiql.org

---

2. Comparison with AsterixDB:
   • Asked by Asinrus@ on community.partiql.org

AsterixDB is a full DBMS–an implementation of SQL++ as well as a storage engine.

PartiQL is also an implementation of SQL++ but it includes no storage engine. This makes it easy to connect to existing storage engines–particularly document-based, semi-structured storage engines.

Answered by @dlurton on community.partiql.org

---

3. Why yet another query engine
   • Asked by mhdwrk2@ on community.partiql.org

Original Question:
Couldn’t you achieve the same design tenets via other query engines like SparkSQL? Seems that SparkSQL can do the same as long as the underlying data storage can be exposed as a DataFrame (similar to PartiQL Data Model).

The open source provides a lightweight reference engine for PartiQL, so that the community can easily check compatibility of syntax, semantics and also use the parser, etc.

Answered by yannip@ on community.partiql.org

I can give a little bit of background in addition to what @yannip says. We needed something really small and light to explore and demonstrate what we wanted to do. SparkSQL and Calcite are great projects and I’d love to figure out how PartiQL can fit with them some day. Spark SQL in particular has a very traditional schema required (i.e. only statically typed) implementation. Calcite (at least the many moons ago that I looked into it) was similar. The dynamic typing (schema optional) and every type being first-class are examples a big enough differences that I thought just implementing something completely from the ground up was warranted for this purpose rather than having to refactor a code base serving a different purpose.

It also happens that the library happens to be a easy to embed, so it has practical usage beyond a pure reference, but the goal of the codebase wasn’t/isn’t necessarily to be a grand database engine or replace the ones out there.

Hope that helps at least provides some context.

Answered by @almann on community.partiql.org