[pgrouting-dev] Version, version, who has the version
Dave Potts
dave.potts at pinan.co.uk
Tue May 28 22:33:33 PDT 2013
On 29/05/13 06:20, Daniel Kastl wrote:
Looks great as long as it returns all the information required for
debugging pg route that can not be got from elsewhere. It returns
information about which version of the pgr code has been used, but does
it include the version information for the dependency of libraries used
to build pgr?
For example if I use select postgis_version
I get 2.0 USE_GEOS=1 USE_PROJU=1 USE_STATS=1
postgis_full_version
POSTGIS="2.0.0 r9605" GEOS="3.3.8-CAPI-1.7.82 PROJ="Rel.4.8.0, 6 March
2012" GDAL="GDAL 1.9.2, release 2012/10/08" LIBJSON="UNKNOWN" RASTER
With this information I would known everything required to build the
right version of postgis, does'nt pgr include some support from some
3rd party libraries?
I am just thinking about the next time, a bug report is raised!
Dave.
*//*
<https://www.google.co.uk/search?client=ubuntu&hs=k3u&channel=cs&biw=1325&bih=870&q=libraries&spell=1&sa=X&ei=-5GlUeK1GOmX0QWK94DwBw&ved=0CCwQvwUoAA>
>
>
>
> On Wed, May 29, 2013 at 1:17 PM, Daniel Kastl <daniel at georepublic.de
> <mailto:daniel at georepublic.de>> wrote:
>
>
>
>
> On Wed, May 29, 2013 at 12:53 PM, Stephen Woodbridge
> <woodbri at swoodbridge.com <mailto: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>
> <mailto:woodbri at swoodbridge.com
> <mailto: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 <mailto:daniel.kastl at georepublic.de>
> Web: http://georepublic.de <http://georepublic.de/>
>
>
> _______________________________________________
> pgrouting-dev mailing list
> pgrouting-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/pgrouting-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/pgrouting-dev/attachments/20130529/3b60571b/attachment.html>
More information about the pgrouting-dev
mailing list