Will SQLite support GQL or SQL/PGQ in the future?
(1) By anonymous on 2021-06-19 17:51:12 [link]
Hi, Recently, interest in graph databases has increased. WG3 is currently working on a new query language standard (ISO / IEC CD 9075-16 or ISO / IEC WD 39075) that would eventually extend the existing SQL. This is a big step towards using DBMSes in a 'graph' way, but there are still no embedded solutions operating on a single file in this area. Do the developers/maintainers of SQLite plan to support the features that will arise from mentioned above standards? Many dependent applications and libraries would benefit from this ;)
(2) By anonymous on 2021-06-26 10:15:34 in reply to 1 [link]
OP here, just bumping, maybe this thread got lost in the middle of bug reports and feature requests. Any opinions?
(3) By Stephan Beal (stephan) on 2021-06-26 10:31:42 in reply to 2 [link]
> Any opinions? This topic and its very close cousin, stored procedures, have been beaten to death multiple times in the past. > Will SQLite support GQL or SQL/PGQ in the future? Management summary: no, for diverse reasons. See (78a60bdeec7c1ee9) for a recent thread on the topic.
(4) By anonymous on 2021-06-26 12:01:27 in reply to 3
I would have liked to get some reasons WHY GPL should be done and why with an embedded db engine. Where would the OP see any advantage over Relational DB sql? Could that also be achieved with a virtual table implementation?
(5) By anonymous on 2021-06-26 15:35:35 in reply to 4 [link]
OP here. > Could that also be achieved with a virtual table implementation? In general cases, yes, that would solve the issue. > I would have liked to get some reasons WHY GPL should be done and why with an embedded db engine. Where would the OP see any advantage over Relational DB sql? As for schema generation the gain would be minimal. The part where it can really be handy is a traversal query with pattern matching. In order to achieve it now (especially for complex schema), user has to specify a query with tons of JOINs; whereas in graph-oriented queries he/she would only specify a pattern (with some additional conditions regarding 'vertices' and 'edges' and how deep the connection should be). So the data would be stored the same way as it is stored now, the only things that would change are the query compiler stack, query planner and VDBE. Of course, there is a potential performance risk, but since data is stored still in tables, regular indexes may improve the performance to some degree. As for why with an embedded db engine: Currently there are no good server-less (also one file) graph db candidates that can be used on a wide range of devices. Then I heard about SQL/PGQ work and decided to ask here whether this feature would be welcome.
(6) By MBL (RoboManni) on 2021-06-27 11:05:36 in reply to 5 [link]
As was written above the question about a graph oriented "language" within SQLite can maybe done with a translation from a value enabled extension table into proper SQL statements. This way the graph language would just act as a simplified syntax for more complicated sql statements. My vision here would be some kind of automated translation of the graph query syntax into normal SQLite3 statements ... even with many join enhancements. I have no fears that SQLite3 would be able to use them ... Without showing examples and advantages for any new query syntax nobody becomes convinced to do in SQLite3 project what other projects are already doing. You, OP, gave a description of what we could work on in this thread - if you want to keep it alive for the purpose of showing where advantages could be expected. Let's start with one use case and show the table structure and the queries in both syntaxes. My experience is that talking about and comparing may make the vision more clear. My idea for syntax transformation from a graph language into sql statements is to use Lua or LuaJIT and its lpeg module with the [statement_vtab](https://sqlite.org/forum/forumpost/28c03d56a16d3301?t=h) as value enabled table extension; the Lemon parser is not known to me .. that could become a final implementation once some advantages would ever become supported natively in C. First make it run and then make it faster and optimized. I see potentials for future to continue looking at graph query languages.
(7.1) By Simon Slavin (slavin) on 2021-06-27 19:28:44 edited from 7.0 in reply to 6 [link]Deleted
(8) By Simon Slavin (slavin) on 2021-06-27 19:29:05 in reply to 1 [link]
This could all be done by writing a GQL engine which used SQLite as a SQL engine. In other words, an API library which called the SQLite API to do its database work. This is permitted by the terms under which SQLite is made available, and could be done without loading SQLite down with features most users don't need. It could use Lemon as a parser, but it wouldn't have to do so. I look forward to seeing your implementation.
(9) By jose isaias cabrera (jicman) on 2021-06-28 20:19:36 in reply to 8 [link]
>I look forward to seeing your implementation. Love that answer. :-)