The JCR 2.0 API defines a QueryResult as having both rows and nodes, where the rows contain the selected property values and the nodes can be used to obtain other information, including the path, name, local name, depth, etc. However, the node's path, name, local name, depth and score (when the query involves a full-text search) simply *cannot* be obtain through the row's values; they must be obtained via specific methods on the javax.jcr.query.Row.

Because the JDBC driver maps the javax.jcr.query.Row.getValues():Value[] to the JDBC result set row, the path, name, local name, depth and score are not visible to any JDBC client. Even if the JDBC driver were to automatically add such columns to the result set, many applications would have to explicitly add support for using the columns since they are not described by the database metadata and certainly are not selectable. In essence, they would be "magic" columns that simply appear despite what the query declares.

A better way to expose this information is to make use of pseudo-columns for the path, name, local name, depth and score. These pseudo-columns would be exposed in database metadata, would be able to be included in the SELECT clause of queries and thus the result sets. Ideally these pseudo-columns could also be used in criteria, since the criteria could be rewritten to use the PATH(), NAME(), LOCALNAME(), DEPTH() and SCORE() functions. For all intents and purposes, these columns would be regular columns from the perspective of JDBC clients.

Note that adding support for the path, name, local name, depth, and score pseudo-columns will also make the query language much more SQL-like, and this will expand the number of existing JDBC clients that can produce the correct/desired JCR queries.