You can create vertex or edge sets from of a given PGQL result set. In the following example, the PGQL query selects all the vertices with values for the property age greater than 24 and then the getVertices() call creates a vertex set containing such vertices.

resultSet = g.queryPgql("SELECT x MATCH (x) WHERE x.age > 24")
vertexSet = g.getVertices(new ResultSetVertexFilter(resultSet, "x"))

This operation is executed on the PGX server when running in client-server mode and removes the need to fetch the result set to the client side in order to create a collection. This brings performance benefits for result sets of any size and enables handling very large result sets that may be troublesome to handle on a client machine.

Graphs can be shared by name, allowing you to mark graphs as shared and retrieve them from any session the graph name. You can mark graphs as shared with other sessions by calling graph.publish(), and other sessions can get a reference to the published graphs via session.getGraph("<name>"). You can see which graphs have been published by calling session.getGraphs(). The owner of a shared graph can modify its name by calling graph.rename("<name>").

Besides graphs, individual properties of a graph can be shared, too, by calling property.publish().

One implication of this feature is that all graph names must now be globally unique across sessions.

The following new built-in algorithms are included for the in-memory analyst:

• Infomap
• Topological Sort and Topological Schedule

You can express existential subqueries. For example:

SELECT a.name, b.name MATCH (a)-[:friendOf]->(b) WHERE
  EXISTS (SELECT * MATCH (a)-[:friendOf]->(c)-[:friendOf]->(b))

You can express a subquery in the WHERE clause of the PATH definition. The following example defines a path ending in a vertex that is not the oldest in the graph:

PATH p AS (a) -> (b) WHERE EXISTS (SELECT * MATCH (x) WHERE x.age > b.age) SELECT ...

One limitation of the current implementation is that only simple constraints (constraints accessing at most one of the pattern variables) are allowed under the WHERE clause. A query that would not be supported is:

PATH p AS (a) -> (b) WHERE EXISTS (SELECT * MATCH (a) -> (c) -> (b)) SELECT ...

You can perform scalar subqueries. For example, the following query selects all the persons whose age is greater than the average age of their friends:

SELECT a.name MATCH (a) WHERE a.age > (SELECT AVG(b.age) MATCH (a)-[:friendOf]->(b))

Other noteworthy new and changed features include the following.

• Introduced a FROM clause for specifying an input graph.
• The FROM clause is optional in PgxGraph#queryPgql(String), PgxGraph#preparePgql(String), and PgxGraph#explainPgql(String).
• The FROM clause is mandatory in PgxSession#queryPgql(String), PgxSession#preparePgql(String), and PgxSession#explainPgql(String).
• The FROM clause is not supported when executing PGQL queries against Oracle Database with OraclePgqlStatement and OraclePgqlPreparedStatement.
• The WHERE clause from PGQL 1.0 has been split up into a MATCH clause and a WHERE clause.
• The MATCH clause contains the graph pattern (vertices, edges and paths) while the WHERE clause in PGQL 1.1 contains only the filter predicates.
• Common path expressions now have an optional WHERE clause for specifying filter expressions (for example, PATH connects_to AS () -[e]-> () WHERE e.status = 'OPEN' SELECT * MATCH ...).
• Inlined filter predicates through WITH ... have been removed.
• OO-style function-call syntax (for example, x.label() or x.id() has been replaced by functional-style syntax (for example, label(x) or id(x)).
• OraclePgqlResultSet now extends oracle.pgql.lang.ResultSet so a common interface can be used to process PGQL results from both the in-memory analyst and Oracle Database.