[pgrouting-dev] "Status" return type

pgRouting pgrouting-dev
1

Hi all,

Trying to get the documentation structured I felt that it was a good idea to unify our custom types: http://docs.pgrouting.org/dev/src/common/doc/types.html

But there are functions that only return a status and I’m not so happy with examples like:


SELECT * FROM pgr_nodeNetwork('edge_table', 'id', 'the_geom', 'edge_table_noded', 0.000001);

               pgr_nodenetwork
----------------------------------------------
 edge_table_noded generated with: 16 segments
(1 row)


SELECT pgr_createTopology('edge_table', 0.000001, 'the_geom', 'id');

 pgr_createtopology
--------------------
 OK
(1 row)

What about some “pgr_statusResult”, which could contain a status code for example and a status message?

CREATE TYPE pgr_statusResult AS
(
    code float8,
    message text
);

Daniel

–
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de
Web: http://georepublic.de

2

On 5/20/2013 11:58 PM, Daniel Kastl wrote:

Hi all,

Trying to get the documentation structured I felt that it was a good
idea to unify our custom types:
http://docs.pgrouting.org/dev/src/common/doc/types.html

But there are functions that only return a status and I'm not so happy
with examples like:

SELECT * FROM pgr_nodeNetwork('edge_table', 'id', 'the_geom', 'edge_table_noded', 0.000001);

                pgr_nodenetwork
----------------------------------------------
  edge_table_noded generated with: 16 segments
(1 row)

SELECT pgr_createTopology('edge_table', 0.000001, 'the_geom', 'id');

  pgr_createtopology
--------------------
  OK
(1 row)

What about some "pgr_statusResult", which could contain a status code
for example and a status message?

CREATE TYPE pgr_statusResult AS
(
     code float8,
     message text
);

Daniel,

99.9% of the time we have an error we would never get control to return a record like this without a LOT of code changes.

The only time we this type of response is a procedure that does some kind of potentially long running batch operation and the response is more to inform the user we are done.

I know we are trying to standardize things but I can not see any vlaue for doing this given that most of the time we would not return error codes because plpgsql does not support returning a complex error status so we would have to code around doing that and we probably have better things to focus on.

I'm willing to be persuaded otherwise if there are good arguments for doing this.

I do understand the lack of standardization in these messages. Maybe we can return more useful messages.

-Steve

3

I'm willing to be persuaded otherwise if there are good arguments for
doing this.

I do understand the lack of standardization in these messages. Maybe we
can return more useful messages.

Well, I just thought it could make testing easier. And it makes
documentation a bit easier (if we care at all about the returned value of
these kind of functions).
Because now once you have "OK" returned, another time it might be a full
text. I didn't think so much about returning errors.

But I agree its not important. And it wouldn't be a problem to add this
later, because right now nobody needs the returned message of these
functions.

Daniel

--
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de
Web: http://georepublic.de