[pgrouting-users] RFC3 Positional and named parameters on pgRouting functions

Dear Users and developers

We would like to hear your feedback about:
Positional and named parameters on pgRouting functions
That is described here:
https://github.com/pgRouting/admin/wiki/RFC3

The aim is to enforce positional notation on compulsory parameters and allow named notation on optional parameters
That enforcement would take place on version 3.0.0 scheduled to be released on September 2019.

We will appreciate your feedback.

Regards

The pgRouting team

···
Georepublic UG (haftungsbeschränkt)
Salzmannstraße 44, 
81739 München, Germany

Vicky Vergara
Operations Research

eMail: vicky@[georepublic.de](http://georepublic.de)
Web: [https://georepublic.info](https://georepublic.info)

Tel: +49 (089) 4161 7698-1
Fax: +49 (089) 4161 7698-9

Commercial register: Amtsgericht München, HRB 181428
CEO: Daniel Kastl

Hi Vicky,

I agree with your proposal.

There is maybe one point, which we would loose, when we remove the names on compulsory parameter: code readability.

Take your example:
https://github.com/pgRouting/admin/wiki/RFC3#developers-steps-to-take

Now it’s not so easy anymore to understand the first three input parameters, so I would suggest to somehow encourage developers (or make it a required formal rule) to append the parameter name in each line as a comment.

CREATE OR REPLACE FUNCTION pgr_aStarCost(
---------------- remove the names on compulsory parameters
TEXT, # edges_sql (required)
BIGINT, # start_vid (required)
BIGINT, # end_vid (required)
directed BOOLEAN DEFAULT true,

I understand, that PostgreSQL does not allow us to use the same attribute name twice for in IN and OUT parameters, if we want to use named parameters. But isn’t this something that could be solved in future versions of PostgreSQL? Looks more like a bug than a feature, because why would someone want to use the parameter name of one, that is defined as “OUT”?

Best regards,
Daniel

···

Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de
Web: https://georepublic.info

Can we ensure that the following issues are taken care of

Its clearly explained how to port old code to use the new systems for the last years worth of releases.
Any attempt to use old signature method name with a new signature some results in some type of massive error along the lines your need to update you code.
The current documentation is updated.
Any new code or code that is being developed has to use the new methods

There is a lot of old code out there, we need a clear method of ensure it can be updated by somebody who has never seen pgrouting before

On Wed, 24 Oct 2018 at 19:44, Vicky Vergara <vicky@georepublic.de> wrote:

Dear Users and developers

We would like to hear your feedback about:
Positional and named parameters on pgRouting functions
That is described here:
https://github.com/pgRouting/admin/wiki/RFC3

The aim is to enforce positional notation on compulsory parameters and allow named notation on optional parameters
That enforcement would take place on version 3.0.0 scheduled to be released on September 2019.

We will appreciate your feedback.

Regards

The pgRouting team

Georepublic UG (haftungsbeschränkt)
Salzmannstraße 44, 
81739 München, Germany

Vicky Vergara
Operations Research

eMail: vicky@[georepublic.de](http://georepublic.de)
Web: [https://georepublic.info](https://georepublic.info)

Tel: +49 (089) 4161 7698-1
Fax: +49 (089) 4161 7698-9

Commercial register: Amtsgericht München, HRB 181428
CEO: Daniel Kastl


Pgrouting-users mailing list
Pgrouting-users@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/pgrouting-users

Hi Dave,

Thanks a lot for the feedback!

The proposal, we’re talking about, will apply for the next major release of pgRouting. And major releases often imply some “breaking changes”, because sometimes wrong decisions have been made, and major releases try to fix them.

There will be definitely documentation, that explains breaking changes and what to care about when upgrading. Eventually there are ways to provide even more user-friendly upgrade tools. Suggestions are always welcome!

However, the RFC3 proposal actually tries to make function syntax more reliable. By using named parameters the order or number of function parameters may change but your application will still work.

Best regards,
Daniel

···

Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de
Web: https://georepublic.info

Hi Dave,

“Normally” people use functions with positional parameters.
(about my quotes in words read [1])

Using proposed function pgr_dijkstraCost as example:

When you write a function call:
SELECT * FROM pgr_dijkstraCost(‘SELECT * from edge_table’, 2, 3);

SELECT * FROM pgr_dijkstraCost(‘SELECT * from edge_table’, 2, 3, false);
This works also (mixed)

SELECT * FROM pgr_dijkstraCost(‘SELECT * from edge_table’, 2, 3, directed:=false);

No one has complained that this can’t be done on 2.6 (or for the last 2 years for that matter) on the function pgr_dijkstraCost:

SELECT * FROM pgr_dijkstraCost(edge_sql:=‘SELECT * from edge_table’, start_vid:=2, end_vid:=3);
I would think that is because “normally” people use functions with positional parameters.

The changes are on the function calls, not on the function’s return column names.

So if you application has a wrapper:
CREATE FUNCTION mywarper1(…)


RETURN QUERY

SELECT end_vid, cost FROM pgr_dijkstraCost(‘SELECT * from edge_table’, 2, 3);

The columns end_vid & cost names are not changed, so your warpper is ok

In the case of pgr_dijkstra
in 2.6 this can be done
SELECT * FROM pgr_dijkstra(end_vid:=3, start_vid:=2, edge_sql:=‘SELECT * from edge_table’);

So if you application has a wrapper:
CREATE FUNCTION mywarper2(…)


RETURN QUERY

SELECT * FROM pgr_dijkstra(end_vid:=3, start_vid:=2, edge_sql:=‘SELECT * from edge_table’);

you will need to change your wrapper

CREATE FUNCTION mywarper2(…)


RETURN QUERY

SELECT * FROM pgr_dijkstra(‘SELECT * from edge_table’, 2, 3);

But the output columns are not affected, so other queries that use the mywrapper2 should remain the same

Regards

Vicky

[1] https://twitter.com/jodygarnett/status/1054257267095171072

···
Georepublic UG (haftungsbeschränkt)
Salzmannstraße 44, 
81739 München, Germany

Vicky Vergara
Operations Research

eMail: vicky@[georepublic.de](http://georepublic.de)
Web: [https://georepublic.info](https://georepublic.info)

Tel: +49 (089) 4161 7698-1
Fax: +49 (089) 4161 7698-9

Commercial register: Amtsgericht München, HRB 181428
CEO: Daniel Kastl

Hi Daniel, there are INOUT parameters in postgres
But then using them will give the columns a strange ordering
like having the seq column in the second or third column.

···
Georepublic UG (haftungsbeschränkt)
Salzmannstraße 44, 
81739 München, Germany

Vicky Vergara
Operations Research

eMail: vicky@[georepublic.de](http://georepublic.de)
Web: [https://georepublic.info](https://georepublic.info)

Tel: +49 (089) 4161 7698-1
Fax: +49 (089) 4161 7698-9

Commercial register: Amtsgericht München, HRB 181428
CEO: Daniel Kastl