Re: Include commit identifier in version() function - Mailing list pgsql-hackers

From Jeff Janes
Subject Re: Include commit identifier in version() function
Date
Msg-id CAMkU=1x2=8ZO1PqM-ypQhVAaGaqv9cfshnhWehp-fQVvqP=pQQ@mail.gmail.com
Whole thread Raw
In response to Re: Include commit identifier in version() function  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Include commit identifier in version() function
List pgsql-hackers
2011/10/28 Robert Haas <robertmhaas@gmail.com>:
> 2011/10/28 pasman pasmański <pasman.p@gmail.com>:
>> I think, it be useful to include in version() function a hexadecimal
>> identifier of commit, for fast checkout to it in git.
>
> It's sort of impossible to make this accurate, though.  You may have
> patched your tree but not created a commit with those changes before
> you build; or if you have created a commit it may very well not be one
> that's in the public repo, but just something on our system.

Sure, I may be compiling changes that are not committed, but still
knowing the most recent commit/checkout that did happen would have
better granularity than just "9.2devel".  And if that commit hash is
not in the public repo, that is fine, as I would want such a thing for
my own use.

> Moreover, there's no real guarantee that you're compiling from a git
> tree at all; you could well be compiling from a tarball.
>
> All in all I feel like this is a solution in search of a problem.
> People shouldn't be using anything other than a released version in
> production,

That is probably true, but 99+% of the compilations and installs I do
are not intended for production use.  I would be happy to see this
feature in my own dev repository, even if it never did see its way
into production.  (It would already be there, if I knew of a way to
make it happen)

Cheers,

Jeff


pgsql-hackers by date:

Previous
From: Martijn van Oosterhout
Date:
Subject: Re: [GENERAL] Strange problem with create table as select * from table;
Next
From: Tomas Vondra
Date:
Subject: [PATCH] optional cleaning queries stored in pg_stat_statements