Named Parameters Ordering

[cvvergara]

Description of what has been tried to be accomplished during the evolution of pgRuting in terms of standard.
The unwritten story trying to make it written

---

This RFC 3
is about named parameters and unnamed parameters

It does not talk about the way named parameters are ordered for cases when the calls use them prepositionally. (see example 2) of the link.

We have to cases:

• Case 1: Functions that work on either directed graphs or undirected graphs
• Case 2: Functions that work only on directed graphs or only on undirected graphs

Case 1

Functions that work on either directed graphs or undirected graphs

In Functions like pgr_dijkstra that have one named optional parameter

• The optional named parameter is has the name directed, that instructs if the graph is to be consider as directed or as undirected.

In Functions like pgr_aStar that many named optional parameters:

• The first optional named parameter has the name directed, that instructs if the graph is to be consider as directed or as undirected.
• The rest of the parameters will try to fit any similar function ordering. In the case of pgr_aStar as it is the first function with these other optional parameters: [, heuristic] [, factor] [, epsilon] is the one that will lead for other functions.

Example 1: Function does not need heuristic
pgr_foo(Edges SQL [,directed] [, factor] [, epsilon])

Example 2: Invalid definition as the epsilon and factor are in the wrong order (Function does not need heuristic)
pgr_bar(Edges SQL [,directed] [, epsilon] [, factor])`

Example 2: Parameters are a combination of parameter names of 2 different existing functions
pgr_bar(Edges SQL [,directed] [,max_depth] [, factor] [, epsilon])

• directed must be the first one
• max_depth comes from a function that has only that named parameter (see pgr_kruskalBFS )
• [, factor] [, epsilon] take the ordering from pgr_aStar

Case 2

Functions that work only on directed graphs or only on undirected graphs

In Functions like pgr_kruskalBFS that have one named optional parameter:

• There is no need of optional named parameter directed as the function only works for undirected graphs
• The first optional named parameter has the name max_depth is the one that will lead for other new functions.

Example 1: Function needs only max_depth
pgr_foo(Edges SQL [, max_depth])

Example 2: Parameters are a combination of parameter names of 2 different existing functions
pgr_bar(Edges SQL [,max_depth] [, factor] [, epsilon])

• max_depth is first because it comes from a function pgr_kruskalBFS that has less parameters than the function pgr_aStar that has factor, epsilon