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

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Vicky Vergara-2
Dear Users and developers

We would like to hear your feedback about:
Positional and named parameters on pgRouting functions
That is described here:

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
Web: 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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pgrouting-users
Reply | Threaded
Open this post in threaded view
|

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

davep
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 <[hidden email]> wrote:
Dear Users and developers

We would like to hear your feedback about:
Positional and named parameters on pgRouting functions
That is described here:

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
Web: 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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pgrouting-users

_______________________________________________
Pgrouting-users mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pgrouting-users
Reply | Threaded
Open this post in threaded view
|

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

dkastl
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


On Thu, Oct 25, 2018 at 2:42 PM Dave Potts <[hidden email]> wrote:
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 <[hidden email]> wrote:
Dear Users and developers

We would like to hear your feedback about:
Positional and named parameters on pgRouting functions
That is described here:

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
Web: 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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pgrouting-users
_______________________________________________
Pgrouting-users mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pgrouting-users


--
Georepublic UG & Georepublic Japan
eMail: [hidden email]
Web: https://georepublic.info




_______________________________________________
Pgrouting-users mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pgrouting-users
Reply | Threaded
Open this post in threaded view
|

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

Vicky Vergara-2
In reply to this post by davep
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





On Thu, Oct 25, 2018 at 12:42 AM Dave Potts <[hidden email]> wrote:
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 <[hidden email]> wrote:
Dear Users and developers

We would like to hear your feedback about:
Positional and named parameters on pgRouting functions
That is described here:

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
Web: 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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pgrouting-users
_______________________________________________
Pgrouting-users mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pgrouting-users


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

Vicky Vergara
Operations Research

eMail: vicky@georepublic.de
Web: 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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pgrouting-users
Reply | Threaded
Open this post in threaded view
|

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

Vicky Vergara-2
In reply to this post by Vicky Vergara-2
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.

On Wed, Oct 24, 2018 at 8:55 PM Daniel Kastl <[hidden email]> wrote:
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:

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






On Thu, Oct 25, 2018 at 3:44 AM Vicky Vergara <[hidden email]> wrote:
Dear Users and developers

We would like to hear your feedback about:
Positional and named parameters on pgRouting functions
That is described here:

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
Web: 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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pgrouting-users


--
Georepublic UG & Georepublic Japan
eMail: [hidden email]
Web: https://georepublic.info



_______________________________________________
pgrouting-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pgrouting-dev


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

Vicky Vergara
Operations Research

eMail: vicky@georepublic.de
Web: 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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pgrouting-users