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

[Daniel Kastl]

On Wed, May 29, 2013 at 1:17 PM, Daniel Kastl <daniel at georepublic.de> wrote:

>
>
>
> 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.
>
>

I tried this and it works pretty well:

CREATE OR REPLACE FUNCTION public.pgr_version()
  RETURNS TABLE(
"version" varchar,
 tag varchar,
build varchar,
 hash varchar,
branch varchar
) AS
$BODY$
DECLARE

BEGIN
    --return '2.0.0-dev v2.0dev-285-g101f36a sew-devel-2_0';
    RETURN QUERY SELECT '2.0.0-dev'::varchar AS version,'v2.0dev'::varchar
AS tag,
                        '285'::varchar AS build, 'g101f36a'::varchar AS
hash,
                        'sew-devel-2_0'::varchar AS branch;
END;
$BODY$
  LANGUAGE plpgsql IMMUTABLE
  COST 100;

You can run either with "SELECT * FROM pgr_version()"

 psql -U postgres -d doc -c "SELECT * FROM public.pgr_version()"
  version  |   tag   | build |   hash   |    branch
-----------+---------+-------+----------+---------------
 2.0.0-dev | v2.0dev | 285   | g101f36a | sew-devel-2_0
(1 row)

Or just "SELECT pgr_version()"

psql -U postgres -d doc -c "SELECT public.pgr_version()"
                  pgr_version
------------------------------------------------
 (2.0.0-dev,v2.0dev,285,g101f36a,sew-devel-2_0)
(1 row)

I think this should satisfy everyone. No? ;-)

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/9099a64a/attachment-0001.html>