[quizotic]

Well ... I kinda like the query syntax's ability to traverse relationships, nest objects/sub-headings, and apply filters at the level of projected expressions!

This has been done before of course, but I'm not sure I've seen this combination of syntax on an RDB before. It's certainly easier to read and write that a bunch of outer joins.

What would be nice to know is whether this can work on top of an existing PG database, providing easier syntax.

While their last example makes _sense_:

  open_prs := User.<assignee[IS PullRequest] {  
      title
  } FILTER .status = 'Open'

I don't find it easy to read/understand. If the [bracketed expression] acts as a filter, why not:

  open_prs := User.<assignee[IS PullRequest AND 
                            .status='open'].title

which preserves the nice dot-chaining for link traversal.

[RedCrowbar]

> What would be nice to know is whether this can work on top of an existing PG database, providing easier syntax.

That would require introspecting arbitrary relational schemas and trying to represent them as an object graph. I don't think something like this can be done automatically and reliably.

That said, we have a tentative plan to introduce support for external databases (through FDWs, so not necessarily Postgres). The mapping specification would have to be explicit though.

[quizotic]

Glad to hear about the FDWs ... but wouldn't foreign keys be your friend here? What else would you need, really, to layer this on an existing DB?

[RedCrowbar]

The [bracketed expression] is a target object type specifier in a path expression and can appear at any point in the path:

  User.<assignee[IS PullRequest].assignees[IS User].name

The reason for the FILTER clause is that you may want to write something like:

  FILTER User.name = 'Alice' OR User.<assignee[IS PullRequest].status = 'Open'

which is impossible to express if we were to simply filter each node set in the path separately.