Comparing changes

Implementation of SQL property graph queries, according to SQL/PGQ standard (ISO 9075-16:2023). Author: Peter Eisentraut <[email protected]> Author: Ashutosh Bapat <[email protected]> Discussion: https://www.postgresql.org/message-id/flat/[email protected] Description of fixes added to the original patch 1. Fixes suggested by pgperltidy. 2. binary_upgrade_set_pg_class_oid() call fix: After 6e1c4a0 binary_upgrade_set_pg_class_oid() doesn't need the (now non-existent) last argument. 3. decompile_column_index_array() call fix: 89f908a added a new parameter withPeriod to decompile_column_index_array(). This function is used to decompile keys in property graph definition. KEYs in property graph definition are not temporal and thus do not need to specify PERIOD in their definition. Hence pass `false` to decompile_column_index_array() when called for while decompiling a property graph definition. 4. Spurious column not found error: Attribute name from a heap tuple needs to be copied before releasing the resources held by the tuple and the table scan. 5. Merge conflict fixes in parser.pl: after ECPG related refactoring from commits around 6b00549. 6. Merge conflict in alter.c and aclchk.c when merging with HEAD = aac831c 7. Fix compilation error in propgraph_element_get_key(): RelationGetPrimaryKeyIndex(), called by propgraph_element_get_key() requires a second argument specifying whether DEFERRED primary key constraints are acceptable. SQL/PGQ standard section 9.12, Syntax Rule 4 mentions only primary key and does not discuss DEFERREDness. Fix compilation failure by passing "true" to RelationGetPrimaryKeyIndex() as second argument. No adjustment to the documentation is needed since it mentioned primary key without DEFERREDness. 8. Merge conflict fixes to gram.y, psql-ref.sgml, psql/help.c, primnodes.h when merging with HEAD = fd4c4ed 9. Merge conflict fixes to gram.y, describe.c and parallel_schedule when merging with HEAD = 75eb976

A cyclic path pattern is a path patterns where an element pattern variable repeats in multiple element path patterns. In such a path pattern the element patterns with the same variable indicate the same element in the path. Elements which share the variable name should have the same element type. The element patterns sharing the same variable name should have same label expression. The patterns may be have different conditions which are finally ANDed since they all represent the same element. While it's easy to imagine a repeated vertex pattern, a repeated edge pattern is slightly complex. An edge connects only two vertices, and thus a repeated edge pattern constrains the adjacent vertex patterns even if they have different variable names. Such patterns are not supported. Author: Ashutosh Bapat

1. A query containing GRAPH_TABLE reference used in a UDF causes segmentation fault: Earlier version of patches used p_post_columnref_hook to transform a property reference in a GRAPH_TABLE reference. But related hooks and members in ParseState are used by other non-core modules like plpgsql. If a query inside a plpgsql function has GRAPH_TABLE reference in it the usage of these hooks conflicts. Since GRAPH_TABLE is a core feature, it's better to introduce a new member ParseState::p_graph_table_pstate, of type GraphTableParseState, to hold the namespace for the GRAPH_TABLE reference being transformed. It is inline with ParseState::p_parent_cte or ParseState::p_queryEnv which have similar purposes. With that change definition of GraphTableParseState is moved to parsenodes.h where CommonTableExpr and QueryEnvironment are also defined. The function using the ParseState::p_graph_table_pstate is renamed to transformGraphTablePropertyRef() to be inline with names of other similar functions. This change also allows GraphTableParseState argument to be removed from a few functions. 2. ERROR: unrecognized lock mode: 0 via ScanQueryForLocks(): After fixing the first bug, I ran into above error. An RTE_GRAPH_TABLE is converted to RTE_SUBQUERY after transformation with relid = OID of the property graph being referenced in GRAPH_TABLE clause. Functions called from ScanQueryForLocks() take locks when RangeTblRef::relid is valid; which is desirable since we want to lock the property graph while it's being used. So set RangeTblRef::rellockmode to AccessShareLock. 3. Prohibits subquery within GRAPH_TABLE reference: In order to support it the hasSublinks flag needs to be transferred to the queries produced as a result of rewriting graph table RTE. It needs a bit of code and some non-trivial testing. So not done right now. 4. Support edge patterns in any direction: Such edge patterns satisfy edges in either direction. 5. If there are multiple foreign keys on an edge table, the last one that appears in the list returned by RelationGetFKeyList() is used to create a vertex reference from that edge. This may lead to wrong edge-vertex linkage. Remember the correct one instead. 6. Node read and write functions did not read and write the relkind, rellockmode and perminfoindex even when those are used in a graph table RangeTblEntry. Fix that. Additional changes 1. Test for a join between GRAPH_TABLE and a regular table. 2. Changed a few loops over lists to use foreach_node reducing and simplifying code a bit. 3. Improved comments. Author: Ashutosh Bapat Reported By: Ajay Pal, Junwang Zhou

Access to the property graph referenced in GRAPH_TABLE clause and the base relations underlying the graph pattern specified in that clause are governed by the following rules. 1. A user needs SELECT privilege to access a property graph in the query. 2. The property graph itself acts similar to a security invoker view in the sense that the current_user should have privileges to access the tables and columns, underlying the graph pattern. For example, a property graph g1 contains graph element tables e1 and e2. Assume two users u1 and u2 with privileges to access e1 and e2 respectively. Let's also assume that they have privileges to access the property graph g1. u1, as the current user, would be able to run query involving g1 successfully as long as it does *not* require access to e2. Similarly u2 would be able to run query involving g1 successfully as long as it does *not* require access to e1. 3. If a property graph is referenced in a security definer view, access to the property graph is governed by the privileges of the owner of the view but the access to the base relations underlying the graph pattern are governed by the privileges of the user executing the query. This is similar to how access to the base relations underlying a security invoker view referenced from a security definer view is handled. access 4. We have not implemented security definer property graphs since SQL/PGQ standard does not mention those. Note: The privileges tests defined views which are owned by users other than the table owners. Right now, property graph can not contain relations which are not owned by its owner. Hence I have not added tests for testing view access through property graphs. Per SQL/PGQ standard, a property graph can contain any relation as long as it has SELECT privilege on that relation. Once we implement what standard says, we can add the tests with views and preferrably add the views as edge tables. Author: Ashutosh Bapat <[email protected]> Discussion: https://www.postgresql.org/message-id/flat/[email protected]

The commit has following changes. 1. collation of a property -------------------------- The values with differing collations can not be collated. This means that we will not able to compare, sort, or order values of properties with the same name if they have different collations in different elements or different labels. This restricts the property's usage in graph table query. Hence the collation of all the properties with the same name needs to be the same. Enforce this. Often the collation of a property reference is required before graph_table is rewritten. For example, assign_query_collation() is called during transformSelectStmt() which is called before calling rewriteGraphTable(). Hence the collation of a property needs to be accessible before any property reference is accessed. Hence the collation of a property is stored in pg_propgraph_property. Note: This is not explicitly specified in Section 9.15, "Consistency check of a tabular property graph descriptor", syntax rule 4.c.iii.2 of SQL/PGQ standard. 2. collation of source and destination keys of an edge ------------------------------------------------------ If collations of edge key and the corresponding referenced key differ, an edge may end up being adjacent to undesired vertex. Prohibit such a case when key columns are explicitly specified. When edge and vertex keys are derived from the foreign key constraint, we do not check collations again since the constraint itself ensures one-to-many edge-to-vertex mapping. Note: This is not specified in Section 9.14, "Creation of an edge table descriptor". 3. Edge-vertex link quals ----------------------------------------- When creating an edge element make sure that there exists an equality operators that can be used to match vertex and edge keys. Fail the DDL if such an operator does not exist. Use the same equality operators to build vertex-edge quals in build_edge_vertex_link_quals(). Also add a dependency of the edge on the equality operator so that it can not be dropped without dropping the edge. Note for reviewers: The code in ATAddForeignKeyConstraint() looks up three different equality operators and it's difficult to separate the code looking up just PK=FK operators. So could not move some common code to a function which can be used at both places. 4. Tests -------- Adds tests for above items. The collation tests, test that a. the collation is correctly set for the columns projected by GRAPH_TABLE clause. b. quals corresponding to the various WHERE clause in GRAPH_TABLE have correct collation set c. quals corresponding to the edge-vertex links have correct collation set. Note: These tests combined with tests in collate.sql and other collation specific tests indicate that we have covered all scenarios testing collations in the context of GRAPH_TABLE. More collation specific tests may be added as required. Author: Ashutosh Bapat

The commit tests interaction of property graph with RLS. The test queries referencing property graph are crafted from existing queries by using equivalent GRAPH_TABLE constructs. Thus we just make sure that the queries using GRAPH_TABLE constructs behave in the same manner and provide the same output as the corresponding existing queries. The tests covering simple tables, inheritance and partitioned tables establish that the RLS is applied even when the tables are accessed through GRAPH_TABLE. That establishes that the RLS policies will be applied when interacting with other features like recursive policies, prepared statement invalidation, security barrier views, CTE, INSERT ... SELECT, COPY, joins, non-target relations etc. This assumption is based on the current implementation which rewrites GRAPH_TABLE clause well before the RLS policies are added. In case the implementation changes in future, these additional test queries will provide the required extensive coverage. Note: The tests for Bug #15708 are already covered earlier, hence not added again. Author: Ashutosh Bapat <[email protected]>

Assorted grammar and typo fixes. Author: Junwang Zhou Reviewed with minor adjustments by: Ashutosh Bapat

A property graph does not have any columns by itself. Thus it doesn't need the table describing columns in \d[+] output. The patch needs following work 1. Move the code to collect column information in a separate function, which can be skipped for property graphs. This avoids one indentation level and makes describeOneTableDetails() easy to follow. 2. Even though the borders are suppressed there is an extra blank line in \d output. Avoid that. It requires some adjustment to printTableOpt or some minion of printTable to avoid printing everything related to column description table. OR If we decide that we want to output a different description (like sequences) we need to decide what that description should be and then implement the same. Ashutosh Bapat

Commit 00f4c29 added support to use expanded mode to all list meta-commands. This commit adds a test to make sure that the support also works for new metacommand \dG added to list property graphs. a14707d introduced relation specific headers in describe output. Adjust it for property graphs. Ashutosh Bapat

This branch was automatically generated by a robot using patches from an email thread registered at: https://commitfest.postgresql.org/patch/4904 The branch will be overwritten each time a new patch version is posted to the thread, and also periodically to check for bitrot caused by changes on the master branch. Patch(es): https://www.postgresql.org/message-id/CAExHW5voR_Jq6bFa4HB+V9p61KFzaMfpJUgU90fVAW+2+r0DrQ@mail.gmail.com Author(s): Peter Eisentraut, Ashutosh Bapat

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Comparing changes

Open a pull request

Commits on Mar 18, 2025

This comparison is taking too long to generate.