[pgrouting-dev] Version, version, who has the version

Daniel Kastl daniel at georepublic.de
Tue May 28 21:17:32 PDT 2013


On Wed, May 29, 2013 at 12:53 PM, Stephen Woodbridge <
woodbri at swoodbridge.com> wrote:

> On 5/28/2013 11:40 PM, Daniel Kastl wrote:
>
>>
>>
>>
>> On Wed, May 29, 2013 at 12:18 PM, Stephen Woodbridge
>> <woodbri at swoodbridge.com <mailto:woodbri at swoodbridge.**com<woodbri at swoodbridge.com>>>
>> wrote:
>>
>>     On 5/28/2013 10:14 PM, Daniel Kastl wrote:
>>
>>
>>         What about just one "pgr_version()" function?
>>         I don't get the use case where we need two of them ;-)
>>
>>         I think "pgr_version()" should then return the "full" version.
>>
>>
>>     I'm fine with have to two functions.
>>
>>     pgr_full_version()  - this would be the full string with everything
>>     pgr_version()       - this should match version of extension like:
>>                            2.0.0-dev in pgrouting--2.0.0-dev.sql
>>
>>     The full version string is what we want for bug reporting.
>>     The version is what you might want to use in an application to
>>     construct if clauses based on features available in this or that
>>     version of the software.
>>
>>
>> What about
>>
>> pgr_version() -> should match version of extension
>> pgr_version("full") -> full string with everything  (could be also
>> "debug")
>>
>> I know this is not really important discussion, but we did so well in
>> decreasing the number of functions and then we're having multiple ones
>> for just getting the version information ;-)
>> Also I had to add two pages to the function reference somehow.
>>
>> I still like the idea to return a record, because someone could pick
>> what is important if used for an application, like:
>>
>> SELECT * FROM pgr_version();
>>
>> version   | tag     | build | hash     | branch
>> ----------+---------+-------+-**---------+---------------
>> 2.0.0-dev | v2.0dev | 271   | g6eeef9b | sew-devel-2_0
>>
>> So one could get the version with SELECT version FROM pgr_version() in
>> case they really use it for some application for example;
>>
>
> This would require defining a new TYPE, I suppose I we could return text[]
> then you could use array_to_string() to concat them with hyphens.
>
> I don't like the idea of passing arguments to get different strings,
> because I have not seen it on any other apps.
>

Me neither. I would prefer to query for attributes as well.



>
> I would just have leave it as two functions and put them both on one doc
> page. Or if you want it parsed return a text[] array. I'm happy to make the
> changes that is trivial.
>

Do you really need to define new types to return a table?

I just did it like this in another function variant:
https://github.com/pgRouting/pgrouting/blob/sew-devel-2_0/src/common/sql/pgrouting_network_check.sql

I didn't have to create a type for that.

Daniel





-- 
Georepublic UG & Georepublic Japan
eMail: daniel.kastl at georepublic.de
Web: http://georepublic.de
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/pgrouting-dev/attachments/20130529/f800a7e8/attachment.html>


More information about the pgrouting-dev mailing list