postgresql/src/backend/nodes
Tom Lane ff4f889164 Fix bugs with degenerate window ORDER BY clauses in GROUPS/RANGE mode.
nodeWindowAgg.c failed to cope with the possibility that no ordering
columns are defined in the window frame for GROUPS mode or RANGE OFFSET
mode, leading to assertion failures or odd errors, as reported by Masahiko
Sawada and Lukas Eder.  In RANGE OFFSET mode, an ordering column is really
required, so add an Assert about that.  In GROUPS mode, the code would
work, except that the node initialization code wasn't in sync with the
execution code about when to set up tuplestore read pointers and spare
slots.  Fix the latter for consistency's sake (even though I think the
changes described below make the out-of-sync cases unreachable for now).

Per SQL spec, a single ordering column is required for RANGE OFFSET mode,
and at least one ordering column is required for GROUPS mode.  The parser
enforced the former but not the latter; add a check for that.

We were able to reach the no-ordering-column cases even with fully spec
compliant queries, though, because the planner would drop partitioning
and ordering columns from the generated plan if they were redundant with
earlier columns according to the redundant-pathkey logic, for instance
"PARTITION BY x ORDER BY y" in the presence of a "WHERE x=y" qual.
While in principle that's an optimization that could save some pointless
comparisons at runtime, it seems unlikely to be meaningful in the real
world.  I think this behavior was not so much an intentional optimization
as a side-effect of an ancient decision to construct the plan node's
ordering-column info by reverse-engineering the PathKeys of the input
path.  If we give up redundant-column removal then it takes very little
code to generate the plan node info directly from the WindowClause,
ensuring that we have the expected number of ordering columns in all
cases.  (If anyone does complain about this, the planner could perhaps
be taught to remove redundant columns only when it's safe to do so,
ie *not* in RANGE OFFSET mode.  But I doubt anyone ever will.)

With these changes, the WindowAggPath.winpathkeys field is not used for
anything anymore, so remove it.

The test cases added here are not actually very interesting given the
removal of the redundant-column-removal logic, but they would represent
important corner cases if anyone ever tries to put that back.

Tom Lane and Masahiko Sawada.  Back-patch to v11 where RANGE OFFSET
and GROUPS modes were added.

Discussion: https://postgr.es/m/CAD21AoDrWqycq-w_+Bx1cjc+YUhZ11XTj9rfxNiNDojjBx8Fjw@mail.gmail.com
Discussion: https://postgr.es/m/153086788677.17476.8002640580496698831@wrigleys.postgresql.org
2018-07-11 12:07:20 -04:00
..
Makefile Introduce extensible node types. 2016-02-12 09:38:11 -05:00
README Fix various common mispellings. 2016-06-03 16:08:45 +01:00
bitmapset.c Post-feature-freeze pgindent run. 2018-04-26 14:47:16 -04:00
copyfuncs.c Assorted cosmetic cleanup of run-time-partition-pruning code. 2018-06-10 18:24:34 -04:00
equalfuncs.c Revert MERGE patch 2018-04-12 11:22:56 +01:00
extensible.c Update copyright for 2018 2018-01-02 23:30:12 -05:00
list.c Rewrite list_qsort() to avoid trashing its input list. 2018-01-09 13:25:53 -05:00
makefuncs.c Update copyright for 2018 2018-01-02 23:30:12 -05:00
nodeFuncs.c Revert MERGE patch 2018-04-12 11:22:56 +01:00
nodes.c Update copyright for 2018 2018-01-02 23:30:12 -05:00
outfuncs.c Fix bugs with degenerate window ORDER BY clauses in GROUPS/RANGE mode. 2018-07-11 12:07:20 -04:00
params.c Update copyright for 2018 2018-01-02 23:30:12 -05:00
print.c Update copyright for 2018 2018-01-02 23:30:12 -05:00
read.c Post-feature-freeze pgindent run. 2018-04-26 14:47:16 -04:00
readfuncs.c Assorted cosmetic cleanup of run-time-partition-pruning code. 2018-06-10 18:24:34 -04:00
tidbitmap.c Update copyright for 2018 2018-01-02 23:30:12 -05:00
value.c Change internal integer representation of Value node 2018-03-13 09:56:25 -04: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 want to 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