Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commit3cd0ac9

Browse files
committed
Doc: rearrange high-level commentary about node support coverage.
copyfuncs.c and friends no longer seem like great places to puthigh-level remarks about what's covered and what isn't. Move thatmaterial to backend/nodes/README and other more-prominent places.Add back (versions of) some remarks that disappeared in2be87f0.Discussion:https://postgr.es/m/3843645.1657385930@sss.pgh.pa.us
1 parent8c73c11 commit3cd0ac9

File tree

4 files changed

+41
-25
lines changed

4 files changed

+41
-25
lines changed

‎src/backend/nodes/README

Lines changed: 25 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -6,10 +6,34 @@ Node Structures
66
Introduction
77
------------
88

9+
Postgres uses "node" types to organize parse trees, plan trees, and
10+
executor state trees. All objects that can appear in such trees must
11+
be declared as node types. In addition, a few object types that aren't
12+
part of parse/plan/execute node trees receive NodeTags anyway for
13+
identification purposes, usually because they are involved in APIs
14+
where we want to pass multiple object types through the same pointer.
15+
916
The node structures are plain old C structures with the first field
1017
being of type NodeTag. "Inheritance" is achieved by convention:
1118
the first field can alternatively be of another node type.
1219

20+
Node types typically have support for being copied by copyObject(),
21+
compared by equal(), serialized by outNode(), and deserialized by
22+
nodeRead(). For some classes of Nodes, not all of these support
23+
functions are required; for example, executor state nodes don't
24+
presently need any of them. So far as the system is concerned,
25+
output and read functions are only needed for node types that can
26+
appear in parse trees stored in the catalogs, and for plan tree
27+
nodes because those are serialized to be passed to parallel workers.
28+
However, we provide output functions for some other node types as well,
29+
because they are very handy for debugging. Currently, such coverage
30+
exists for raw parsetrees and most planner data structures. However,
31+
output coverage of raw parsetrees is incomplete: in particular, utility
32+
statements are almost entirely unsupported.
33+
34+
Relevant Files
35+
--------------
36+
1337
Utility functions for manipulating node structures reside in this
1438
directory. Some support functions are automatically generated by the
1539
gen_node_support.pl script, other functions are maintained manually.
@@ -40,7 +64,7 @@ FILES IN THIS DIRECTORY (src/backend/nodes/)
4064

4165
FILES IN src/include/nodes/
4266

43-
Node definitions:
67+
Node definitions primarily appear in:
4468
nodes.h- define node tags (NodeTag) (*)
4569
primnodes.h- primitive nodes
4670
parsenodes.h- parse tree nodes

‎src/backend/nodes/outfuncs.c

Lines changed: 0 additions & 13 deletions
Original file line numberDiff line numberDiff line change
@@ -10,19 +10,6 @@
1010
* IDENTIFICATION
1111
* src/backend/nodes/outfuncs.c
1212
*
13-
* NOTES
14-
* Every node type that can appear in stored rules' parsetrees *must*
15-
* have an output function defined here (as well as an input function
16-
* in readfuncs.c). In addition, plan nodes should have input and
17-
* output functions so that they can be sent to parallel workers.
18-
*
19-
* For use in debugging, we also provide output functions for nodes
20-
* that appear in raw parsetrees and planner Paths. These node types
21-
* need not have input functions. Output support for raw parsetrees
22-
* is somewhat incomplete, too; in particular, utility statements are
23-
* almost entirely unsupported. We try to support everything that can
24-
* appear in a raw SELECT, though.
25-
*
2613
*-------------------------------------------------------------------------
2714
*/
2815
#include"postgres.h"

‎src/backend/nodes/readfuncs.c

Lines changed: 1 addition & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -11,16 +11,12 @@
1111
* src/backend/nodes/readfuncs.c
1212
*
1313
* NOTES
14-
* Path nodes do not have any readfuncs support, because we never
15-
* have occasion to read them in. (There was once code here that
16-
* claimed to read them, but it was broken as well as unused.) We
17-
* never read executor state trees, either.
18-
*
1914
* Parse location fields are written out by outfuncs.c, but only for
2015
* debugging use. When reading a location field, we normally discard
2116
* the stored value and set the location field to -1 (ie, "unknown").
2217
* This is because nodes coming from a stored rule should not be thought
2318
* to have a known location in the current query's text.
19+
*
2420
* However, if restore_location_fields is true, we do restore location
2521
* fields from the string. This is currently intended only for use by the
2622
* WRITE_READ_PARSE_PLAN_TREES test code, which doesn't want to cause

‎src/include/nodes/execnodes.h

Lines changed: 15 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -3,11 +3,20 @@
33
* execnodes.h
44
* definitions for executor state nodes
55
*
6-
* ExprState represents the evaluation state for a whole expression tree.
7-
* Most Expr-based plan nodes do not have a corresponding expression state
8-
* node, they're fully handled within execExpr* - but sometimes the state
9-
* needs to be shared with other parts of the executor, as for example
10-
* with SubPlanState, which nodeSubplan.c has to modify.
6+
* Most plan node types declared in plannodes.h have a corresponding
7+
* execution-state node type declared here. An exception is that
8+
* expression nodes (subtypes of Expr) are usually represented by steps
9+
* of an ExprState, and fully handled within execExpr* - but sometimes
10+
* their state needs to be shared with other parts of the executor, as
11+
* for example with SubPlanState, which nodeSubplan.c has to modify.
12+
*
13+
* Node types declared in this file do not have any copy/equal/out/read
14+
* support. (That is currently hard-wired in gen_node_support.pl, rather
15+
* than being explicitly represented by pg_node_attr decorations here.)
16+
* There is no need for copy, equal, or read support for executor trees.
17+
* Output support could be useful for debugging; but there are a lot of
18+
* specialized fields that would require custom code, so for now it's
19+
* not provided.
1120
*
1221
*
1322
* Portions Copyright (c) 1996-2022, PostgreSQL Global Development Group
@@ -53,7 +62,7 @@ struct LogicalTapeSet;
5362
/* ----------------
5463
*ExprState node
5564
*
56-
* ExprStateis thetop-level node for expressionevaluation.
65+
* ExprStaterepresents theevaluation state fora wholeexpressiontree.
5766
* It contains instructions (in ->steps) to evaluate the expression.
5867
* ----------------
5968
*/

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp