postgresql.git/src/include/rewrite, branch master

Revert SQL Property Graph Queries (SQL/PGQ)

2026-09-07T19:00:55Z

List of commits reverted: 2f094e7ac69 SQL Property Graph Queries (SQL/PGQ) cd8844e7db6 Make some tests more stable by adding more explicit ordering 182cdf5aeaf pg_dump: Add appropriate version check c9babbc8816 Dump labels in reproducible order 040a56be4bc Cleanup users and roles in graph_table_rls test 5282bf535e4 Fix some typos and make small stylistic improvements 720f0f89d69 Reject consecutive element patterns of same kind 288ae968726 Add a graph pattern variable only once c5b3253b8ab Property references are preferred over regular column references a0dd0702e46 Fix cross variable references in graph pattern causing segfault 2ff289d0393 Check for stack overflow when rewriting graph queries 9082680c34e Fix typos and grammar in graph table rewrite code ac3bcc041c5 Fix collation of expressions in GRAPH_TABLE COLUMNS clause 9d2979dd685 pg_get_viewdef() and lateral references in COLUMNS of GRAPH_TABLE 891a57c7394 Do not define type for a property graph dc9e7c9ed93 Handle nodes that may appear in GraphPattern expression trees f6edd8ed708 Add ORDER BY to test query to stabilize test 1190f858eaf doc: Small synopsis wording change for consistency d0eac3cafb0 Make spelling consistent 6827de95ee0 Simplify code in objectaddress.c for some property graph objects 5778fb3eafd Fix typo in error message 72498a86989 Handle element label and label property objects in object address functions 4cb2a9863d8 Fix LATERAL references in GRAPH_TABLE with multi-label pattern 9d8cdcbe0c8 Record dependencies on graph labels and properties 2a7e95b659d Readable identity strings for property graph objects 7afa11feca6 Prevent dropping the last label from a property graph element 96418a6da9d Fix handling of dropping a property not associated with the given label efd7d8d7d49 Resolve unknown-type literals in GRAPH_TABLE COLUMNS e0ff7fd9aa2 Make property graph object descriptions better translatable 0e4f0827f63 Fix properties orphaned by dropping a label 73dfe79fd60 Remove apparent support for SECURITY LABEL ON PROPERTY GRAPH 592de8bd21e Fix pg_dump ACL minimization for PROPERTY GRAPH. 16a4b3ef8ee Fix replace_property_refs() ignoring the root of expression tree 57f93af36f0 Resolve unknown-type literals in property expressions 2e6578292a9 Prohibit locking clauses on GRAPH_TABLE 2521f9e75e9 doc: Fix SQL quoting in example 0316593146d Restore the ability to use | and -> as prefix operators. 780fa49746d Fix missing space before WHERE in GRAPH_TABLE deparse fa62d4f6ea7 Prohibit GRANT ... ON TABLE on a property graph 63c3bbb39f9 doc: Add PROPERTY GRAPH to the access privilege tables 0a51a06cdb0 More tab-completion for DROP PROPERTY GRAPH f585671055d Disallow aggregates, window functions, and SRFs in GRAPH_TABLE COLUMNS 9b917a93116 Report duplicate property and label names with a proper error a82e33a83d7 Make generate_queries_for_path_pattern_recurse() interruptible 3c982c9bf1a Add test for view referencing labels shared by vertex and edge tables 8646d1d5904 Fix inferred property graph keys with INCLUDE columns 0417bf52969 Fix pg_event_trigger_ddl_commands for GRANT ON PROPERTY GRAPH a20d3e35f2c doc: reformat GRAPH_TABLE examples 792094a5ce8 Coerce GRAPH_TABLE pattern WHERE clauses to boolean plus typedefs.list changes. Discussion: https://www.postgresql.org/message-id/CAAKRu_bEtjWYWhYxSo0o_t3DaZYRQd5PkC0abA0g9Mp4%2BovH0w%40mail.gmail.com

Perform join removal by editing the query's jointree.

2026-08-28T19:12:26Z

analyzejoins.c decided which joins could be dropped by consulting the planner's derived data structures, but then implemented the removal by updating those structures in-place. That is a lot of fiddly work, and nothing keeps it in step with the rest of the planner: remove_leftjoinrel_from_query only bothered to update "parts of the planner's data structures that will actually be consulted later", with no good way to know what those are. Bug #19560 is one consequence. In that report, removing a join leaves an EquivalenceClass that now gives rise to a base restriction clause, but base restriction clauses have already been generated and nothing reconsiders them, so the WHERE condition disappears from the plan and we return wrong answers. The self-join elimination code has the same design and the same type of hazard. We have seen many related bugs over the years too, so it's time to do something drastic. To fix, do the removals by editing root->parse->jointree (which is a far simpler and more stable representation than the derived data), and then have query_planner() discard everything it computed from the jointree and derive it over again. This requires quite a bit less code, and doesn't require touching analyzejoins.c every time we change the data derived by query_planner(). For typical cases it can actually save a bit of planning time, though in cases where we have to iterate the derivation loop many times it does add some time. reduce_unique_semijoins() gets the same treatment: rather than deleting the semijoin's SpecialJoinInfo and relying on the jointree not being consulted again, it now changes the JoinExpr's jointype to JOIN_INNER and recalculates everything. Some plans change in the join regression test. Qual evaluation order shifts in a few cases, because the conditions now reach later planning in jointree order rather than in whatever order the removal code re-distributed them. A few plans improve, since the rebuilt relation targetlists no longer carry columns that only a removed join needed. We also detect a constant-false filter condition whose test used to carry a FIXME label. One plan gets marginally worse, because the old code recomputed attr_needed from equivalence classes after a join removal; that is more accurate than what deconstruct_jointree() derives from the original clauses, but we no longer do that. Making that recomputation happen anyway could be worth doing, but it should be considered independently and perhaps implemented differently. Back-patch to v16, on the grounds that the introduction of varnullingrels in v16 made the old approach significantly more complex and bug-prone; notably, bug #19560 does not manifest before v16. In released branches, do not remove externally-visible fixup functions such as remove_join_clause_from_rels, in case any extensions are relying on them; but they're no longer used by core code. But we must nonetheless break API/ABI for remove_useless_joins, reduce_unique_semijoins, and remove_useless_self_joins, as those now have different outputs and very different behavior than before. It seems unlikely that any extensions are calling those; but just in case, make the breakage more obvious by renaming remove_useless_joins to remove_useless_outer_joins, which is a more sensible name for it anyway since the addition of remove_useless_self_joins. Full disclosure: initial drafts of this patch were made with Claude Opus 4.8. Bug: #19560 Reported-by: Orestis Markou Author: Tom Lane Reviewed-by: Richard Guo Reviewed-by: Thom Brown Reviewed-by: Jacob Brazeal Discussion: https://postgr.es/m/1186816.1784573544@sss.pgh.pa.us Backpatch-through: 16

Fix bogus calls in remove_self_join_rel()

2026-04-27T01:40:37Z

remove_self_join_rel() called adjust_relid_set() on all_result_relids and leaf_result_relids but threw away the return value. Since adjust_relid_set() returns a freshly-built Relids and does not modify the input in place, the calls did nothing. This has been the case since the SJE feature went in (commit fc069a3a6). There has been no observable misbehavior, because the relid being passed is guaranteed not to be a member of either set. At the point remove_self_join_rel() runs, those sets contain only resultRelation; inheritance children have not been added yet, as that happens later in query_planner(), in expand_single_inheritance_child() called from add_other_rels_to_query(). And remove_self_joins_recurse() rejects parse->resultRelation as an SJE candidate to preserve the EvalPlanQual mechanism. Even with the result assigned, the calls would be no-ops in practice. Rather than make the calls do the cleanup they pretend to do, replace them with assertions of the invariant. Any future loosening of the SJE candidate filter -- for instance to allow eliminating a result relation under provable conditions -- will trip the assertion and force whoever does it to revisit this code. Additionally, decorate adjust_relid_set() with pg_nodiscard so that any future accidental discard of its return value is caught at compile time. Author: Richard Guo Reviewed-by: David Rowley Discussion: https://postgr.es/m/CAMbWs49fYQcqJfJ_Gtn8r1GFNoYtb1=2AUab4ieuqY4Zid9ocQ@mail.gmail.com

Add some const qualifiers enabled by typeof_unqual change on copyObject

2026-03-19T05:35:54Z

The recent commit to change copyObject() to use typeof_unqual allows cleaning up some APIs to take advantage of this improved qualifier handling. EventTriggerCollectSimpleCommand() is a good example: It takes a node tree and makes a copy that it keeps around for its internal purposes, but it can't communicate via its function signature that it promises not scribble on the passed node tree. That is now fixed. Reviewed-by: David Geier Discussion: https://www.postgresql.org/message-id/flat/92f9750f-c7f6-42d8-9a4a-85a3cbe808f3%40eisentraut.org

SQL Property Graph Queries (SQL/PGQ)

2026-03-16T09:14:18Z

Implementation of SQL property graph queries, according to SQL/PGQ standard (ISO/IEC 9075-16:2023). This adds: - GRAPH_TABLE table function for graph pattern matching - DDL commands CREATE/ALTER/DROP PROPERTY GRAPH - several new system catalogs and information schema views - psql \dG command - pg_get_propgraphdef() function for pg_dump and psql A property graph is a relation with a new relkind RELKIND_PROPGRAPH. It acts like a view in many ways. It is rewritten to a standard relational query in the rewriter. Access privileges act similar to a security invoker view. (The security definer variant is not currently implemented.) Starting documentation can be found in doc/src/sgml/ddl.sgml and doc/src/sgml/queries.sgml. Author: Peter Eisentraut Author: Ashutosh Bapat Reviewed-by: Junwang Zhao Reviewed-by: Ajay Pal Reviewed-by: Henson Choi Discussion: https://www.postgresql.org/message-id/flat/a855795d-e697-4fa5-8698-d20122126567@eisentraut.org

Update copyright for 2026

2026-01-01T18:24:10Z

Backpatch-through: 14

Update various forward declarations to use typedef

2025-09-15T09:04:10Z

There are a number of forward declarations that use struct but not the customary typedef, because that could have led to repeat typedefs, which was not allowed. This is now allowed in C11, so we can update these to provide the typedefs as well, so that the later uses of the types look more consistent. Reviewed-by: Chao Li Discussion: https://www.postgresql.org/message-id/flat/10d32190-f31b-40a5-b177-11db55597355@eisentraut.org

Refactor ChangeVarNodesExtended() using the custom callback

2025-05-07T08:10:16Z

fc069a3a6319 implemented Self-Join Elimination (SJE) and put related logic to ChangeVarNodes_walker(). This commit provides refactoring to remove the SJE-related logic from ChangeVarNodes_walker() but adds a custom callback to ChangeVarNodesExtended(), which has a chance to process a node before ChangeVarNodes_walker(). Passing this callback to ChangeVarNodesExtended() allows SJE-related node handling to be kept within the analyzejoins.c. Reported-by: Richard Guo Discussion: https://postgr.es/m/CAMbWs49PE3CvnV8vrQ0Dr%3DHqgZZmX0tdNbzVNJxqc8yg-8kDQQ%40mail.gmail.com Author: Andrei Lepikhov Author: Alexander Korotkov

Revert "Refactor ChangeVarNodesExtended() using the custom callback"

2025-05-03T19:42:05Z

This reverts commit 250a718aadad68793e82103282247556a46a3cfc. It shouldn't be pushed during the release freeze. Reported-by: Tom Lane Discussion: https://postgr.es/m/E1uBIbY-000owH-0O%40gemulon.postgresql.org

Refactor ChangeVarNodesExtended() using the custom callback

2025-05-03T19:30:52Z