On Tuesday, 30 January 2018, Tom Lane <
tgl@sss.pgh.pa.us> wrote:
Another thing I'm a little confused by is the precise API for the in_range
support functions (the lack of any documentation for it doesn't help).
I wonder why you chose to provide two support functions per datatype
combination rather than one with an additional boolean argument.
In fact, it almost seems like the "end" flag could already do the
job, though I may be missing something. As-is, it seems like this
setup involves a lot of duplicate code and catalog entries ... what
are we gaining from that?
regards, tom lane
We could instead remove the "desc" functions and flip the values of both "preceding" and "end" for a descending order. It just needs an extra bool in the parsenode/plannode structs to send to nodeWindowAgg.
I used two functions because it seemed cleaner to me to get the Oid of the function in the parser for both ordering types, so then nodeWindowAgg doesn't have to know about sort order (doesn't have to have extra conditionals for the two). But yes it does increase the catalog and code size so is probably better removed.
I will send out v10 soon with the desc functions removed and the EXCLUDE_NO_OTHERS define removed.