/
githubmirror
/
postgres
Обзор
Документация
Войти
/
githubmirror
/
postgres
Код
Запросы
0
Пакеты
0
Релизы
0
Аналитика
Безопасность
master
src/backend/nodes/README
115 строк
5 KB
Peter Eisentraut
Convert node test compile-time settings into run-time parameters
01 авг 2024, 11:09
01 авг 2024, 11:09
a292c98
Код
Авторство
О чём код?
src/backend/nodes/README Node Structures =============== Introduction ------------ Postgres uses "node" types to organize parse trees, plan trees, and executor state trees. All objects that can appear in such trees must be declared as node types. In addition, a few object types that aren't part of parse/plan/execute node trees receive NodeTags anyway for identification purposes, usually because they are involved in APIs where we want to pass multiple object types through the same pointer. The node structures are plain old C structures with the first field being of type NodeTag. "Inheritance" is achieved by convention: the first field can alternatively be of another node type. Node types typically have support for being copied by copyObject(), compared by equal(), serialized by outNode(), and deserialized by nodeRead(). For some classes of Nodes, not all of these support functions are required; for example, executor state nodes don't presently need any of them. So far as the system is concerned, output and read functions are only needed for node types that can appear in parse trees stored in the catalogs, and for plan tree nodes because those are serialized to be passed to parallel workers. However, we provide output functions for some other node types as well, because they are very handy for debugging. Currently, such coverage exists for raw parsetrees and most planner data structures. However, output coverage of raw parsetrees is incomplete: in particular, utility statements are almost entirely unsupported. Relevant Files -------------- Utility functions for manipulating node structures reside in this directory. Some support functions are automatically generated by the gen_node_support.pl script, other functions are maintained manually. To control the automatic generation of support functions, node types and node fields can be annotated with pg_node_attr() specifications; see further documentation in src/include/nodes/nodes.h. FILES IN THIS DIRECTORY (src/backend/nodes/) General-purpose node manipulation functions: copyfuncs.c - copy a node tree (*) equalfuncs.c - compare two node trees (*) outfuncs.c - convert a node tree to text representation (*) readfuncs.c - convert text representation back to a node tree (*) makefuncs.c - creator functions for some common node types nodeFuncs.c - some other general-purpose manipulation functions queryjumblefuncs.c - compute a node tree for query jumbling (*) (*) - Most functions in these files are generated by gen_node_support.pl and #include'd there. Specialized manipulation functions: bitmapset.c - Bitmapset support list.c - generic list support multibitmapset.c - List-of-Bitmapset support params.c - Param support tidbitmap.c - TIDBitmap support value.c - support for value nodes FILES IN src/include/nodes/ Node definitions primarily appear in: nodes.h - define node tags (NodeTag) (*) primnodes.h - primitive nodes parsenodes.h - parse tree nodes pathnodes.h - path tree nodes and planner internal structures plannodes.h - plan tree nodes execnodes.h - executor nodes memnodes.h - memory nodes pg_list.h - generic list (*) - Also #include's files generated by gen_node_support.pl. Steps to Add a Node ------------------- Suppose you want to define a node Foo: 1. Add the structure definition to the appropriate include/nodes/???.h file. If you intend to inherit from, say a Plan node, put Plan as the first field of your struct definition. (The T_Foo tag is created automatically.) 2. Check that the generated support functions in copyfuncs.funcs.c, equalfuncs.funcs.c, outfuncs.funcs.c, queryjumblefuncs.funcs.c and readfuncs.funcs.c look correct. Add attributes as necessary to control the outcome. (For some classes of node types, you don't need all the support functions. Use node attributes similar to those of related node types.) 3. Add cases to the functions in nodeFuncs.c as needed. There are many other places you'll probably also need to teach about your new node type. Best bet is to grep for references to one or two similar existing node types to find all the places to touch. (Except for frequently-created nodes, don't bother writing a creator function in makefuncs.c.) 4. Consider testing your new code with debug_copy_parse_plan_trees, debug_write_read_parse_plan_trees, and debug_raw_expression_coverage_test to ensure support has been added everywhere that it's necessary (e.g., run the tests with PG_TEST_INITDB_EXTRA_OPTS='-c debug_...=on'). Adding a new node type moves the numbers associated with existing tags, so you'll need to recompile the whole tree after doing this. (--enable-depend usually helps.) It doesn't force initdb though, because the numbers never go to disk. But altering or removing a node type should usually be accompanied by an initdb-forcing catalog version change, since the interpretation of serialized node trees stored in system catalogs is affected by that. (If the node type never appears in stored parse trees, as for example Plan nodes do not, then a catversion change is not needed to change it.)