Skip to content
Snippets Groups Projects
Select Git revision
  • benchmark-tools
  • postgres-lambda
  • master default
  • REL9_4_25
  • REL9_5_20
  • REL9_6_16
  • REL_10_11
  • REL_11_6
  • REL_12_1
  • REL_12_0
  • REL_12_RC1
  • REL_12_BETA4
  • REL9_4_24
  • REL9_5_19
  • REL9_6_15
  • REL_10_10
  • REL_11_5
  • REL_12_BETA3
  • REL9_4_23
  • REL9_5_18
  • REL9_6_14
  • REL_10_9
  • REL_11_4
23 results

nodes

  • Clone with SSH
  • Clone with HTTPS
  • user avatar
    Tom Lane authored
    This patch adds the ability to write TABLE( function1(), function2(), ...)
    as a single FROM-clause entry.  The result is the concatenation of the
    first row from each function, followed by the second row from each
    function, etc; with NULLs inserted if any function produces fewer rows than
    others.  This is believed to be a much more useful behavior than what
    Postgres currently does with multiple SRFs in a SELECT list.
    
    This syntax also provides a reasonable way to combine use of column
    definition lists with WITH ORDINALITY: put the column definition list
    inside TABLE(), where it's clear that it doesn't control the ordinality
    column as well.
    
    Also implement SQL-compliant multiple-argument UNNEST(), by turning
    UNNEST(a,b,c) into TABLE(unnest(a), unnest(b), unnest(c)).
    
    The SQL standard specifies TABLE() with only a single function, not
    multiple functions, and it seems to require an implicit UNNEST() which is
    not what this patch does.  There may be something wrong with that reading
    of the spec, though, because if it's right then the spec's TABLE() is just
    a pointless alternative spelling of UNNEST().  After further review of
    that, we might choose to adopt a different syntax for what this patch does,
    but in any case this functionality seems clearly worthwhile.
    
    Andrew Gierth, reviewed by Zoltán Böszörményi and Heikki Linnakangas, and
    significantly revised by me
    784e762e
    History
    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