A special column, jcr:path, that does not correspond to any actual property is present in node type tables. The jcr:path column holds the normalized absolute path for the node represented by each row.
The jcr:path column always appears in the result table
Note that the actual value of a particular jcr:path column within a particular Row of the result table can be calculated by the implementation at the time that a request is made for that value. For example, on the call someRow.getValue("jcr:path") (where someRow is an instance of Row). This type of “lazy loading” allows implementations to avoid calculating paths for all nodes in the return set at query time. Such an approach would be advantageous for those implementations in which path calculation is expensive.
The jcr:path value returned in a result table will be in compact form, where index notation is only used if necessary, i.e., where lack of an index indicates an implicit index of . However, when a test is performed within a WHERE clause against a jcr:path, the query mechanism will intelligently match both compact and explicit forms of the same path. For example, the following WHERE clauses define the same constraint:
Consequently, to select all same name siblings one uses the following syntax:
WHERE jcr:path LIKE '/foo/bar[%]'
Predicates in the WHERE clause that test jcr:path are only required to support the operators =, <> and LIKE. In the case of LIKE predicates, support is only required for tests using the % wildcard character as a match for a whole path segment (the part between two / characters) or within index brackets. This set of minimum requirements would, for example, allow the following path queries:
jcr:path LIKE '/books/%' AND NOT jcr:path LIKE '/books/%/%'
jcr:path LIKE '/books/mybooks/%'
Descendant or self:
jcr:path LIKE '/books/mybooks/%' OR jcr:path='/books/mybooks'
jcr:path LIKE '/books[%]/mybooks[%]'
See also 188.8.131.52 Property Constraint and 184.108.40.206 Path Constraint.