postgresql/src/backend/nodes
Tom Lane b14953932d Revise FDW planning API, again.
Further reflection shows that a single callback isn't very workable if we
desire to let FDWs generate multiple Paths, because that forces the FDW to
do all work necessary to generate a valid Plan node for each Path.  Instead
split the former PlanForeignScan API into three steps: GetForeignRelSize,
GetForeignPaths, GetForeignPlan.  We had already bit the bullet of breaking
the 9.1 FDW API for 9.2, so this shouldn't cause very much additional pain,
and it's substantially more flexible for complex FDWs.

Add an fdw_private field to RelOptInfo so that the new functions can save
state there rather than possibly having to recalculate information two or
three times.

In addition, we'd not thought through what would be needed to allow an FDW
to set up subexpressions of its choice for runtime execution.  We could
treat ForeignScan.fdw_private as an executable expression but that seems
likely to break existing FDWs unnecessarily (in particular, it would
restrict the set of node types allowable in fdw_private to those supported
by expression_tree_walker).  Instead, invent a separate field fdw_exprs
which will receive the postprocessing appropriate for expression trees.
(One field is enough since it can be a list of expressions; also, we assume
the corresponding expression state tree(s) will be held within fdw_state,
so we don't need to add anything to ForeignScanState.)

Per review of Hanada Shigeru's pgsql_fdw patch.  We may need to tweak this
further as we continue to work on that patch, but to me it feels a lot
closer to being right now.
2012-03-09 12:49:25 -05:00
..
Makefile Remove cvs keywords from all files. 2010-09-20 22:08:53 +02:00
README Remove useless whitespace at end of lines 2010-11-23 22:34:55 +02:00
bitmapset.c Use parameterized paths to generate inner indexscans more flexibly. 2012-01-27 19:26:38 -05:00
copyfuncs.c Revise FDW planning API, again. 2012-03-09 12:49:25 -05:00
equalfuncs.c ALTER TABLE: skip FK validation when it's safe to do so 2012-02-27 19:10:24 -03:00
list.c Update copyright notices for year 2012. 2012-01-01 18:01:58 -05:00
makefuncs.c Update copyright notices for year 2012. 2012-01-01 18:01:58 -05:00
nodeFuncs.c Update copyright notices for year 2012. 2012-01-01 18:01:58 -05:00
nodes.c Update copyright notices for year 2012. 2012-01-01 18:01:58 -05:00
outfuncs.c Revise FDW planning API, again. 2012-03-09 12:49:25 -05:00
params.c Update copyright notices for year 2012. 2012-01-01 18:01:58 -05:00
print.c Update copyright notices for year 2012. 2012-01-01 18:01:58 -05:00
read.c Update copyright notices for year 2012. 2012-01-01 18:01:58 -05:00
readfuncs.c Update copyright notices for year 2012. 2012-01-01 18:01:58 -05:00
tidbitmap.c Update copyright notices for year 2012. 2012-01-01 18:01:58 -05:00
value.c Update copyright notices for year 2012. 2012-01-01 18:01:58 -05:00

README

src/backend/nodes/README

Node Structures
===============

Andrew Yu (11/94)

Introduction
------------

The current node structures are plain old C structures. "Inheritance" is
achieved by convention. No additional functions will be generated. Functions
that manipulate node structures reside in this directory.


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

    Specialized manipulation functions:
	bitmapset.c	- Bitmapset support
	list.c		- generic list support
	params.c	- Param support
	tidbitmap.c	- TIDBitmap support
	value.c		- support for Value nodes

FILES IN src/include/nodes/

    Node definitions:
	nodes.h		- define node tags (NodeTag)
	primnodes.h	- primitive nodes
	parsenodes.h	- parse tree nodes
	plannodes.h	- plan tree nodes
	relation.h	- planner internal nodes
	execnodes.h	- executor nodes
	memnodes.h	- memory nodes
	pg_list.h	- generic list


Steps to Add a Node
-------------------

Suppose you wanna define a node Foo:

1. Add a tag (T_Foo) to the enum NodeTag in nodes.h.  (If you insert the
   tag in a way that moves the numbers associated with existing tags,
   you'll need to recompile the whole tree after doing this.  It doesn't
   force initdb though, because the numbers never go to disk.)
2. 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.
3. If you intend to use copyObject, equal, nodeToString or stringToNode,
   add an appropriate function to copyfuncs.c, equalfuncs.c, outfuncs.c
   and readfuncs.c accordingly.  (Except for frequently used nodes, don't
   bother writing a creator function in makefuncs.c)  The header comments
   in those files give general rules for whether you need to add support.
4. 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.


Historical Note
---------------

Prior to the current simple C structure definitions, the Node structures
used a pseudo-inheritance system which automatically generated creator and
accessor functions. Since every node inherited from LispValue, the whole thing
was a mess. Here's a little anecdote:

    LispValue definition -- class used to support lisp structures
    in C.  This is here because we did not want to totally rewrite
    planner and executor code which depended on lisp structures when
    we ported postgres V1 from lisp to C. -cim 4/23/90