Re: Adding optionally commit number in PG_VERSION_STR

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Adding optionally commit number in PG_VERSION_STR
Date: 2013-07-17 03:27:39
Message-ID: 3038.1374031659@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Michael Paquier <michael(dot)paquier(at)gmail(dot)com> writes:
> It happens that I work occasionally on multiple builds based on
> different stable branches at the same time to check fixes that need to
> be backpatched, and I tend to easily lose track on which version the
> build I created is based on (Duh!). There is of course the version
> number up to the 3rd digit available (for example 9.2.4, 9.3beta2,
> etc.), but as a developer I think that it would be helpful to include
> the commit ID in PG_VERSION_STR to get a better reference on exactly
> what the development build is based on. This could be controlled by an
> additional flag in ./configure.in called something like
> --enable-version-commit, of course disabled by default. If enabled,
> PG_VERSION_STR would be generated with the new information. configure
> would also return an error when this flag is enabled if git is either
> not found, or if the repository where configure is not a native git
> repository.

Personally, I'd find that pretty useless, because the build I'm running
has typically got uncommitted changes in it. Also, there isn't any good
way to set PG_VERSION_STR except at configure time, which means the
common practice of doing (at most) "make clean" before rebuilding would
not result in an updated string even if you had committed.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ants Aasma 2013-07-17 03:36:26 Re: Improvement of checkpoint IO scheduler for stable transaction responses
Previous Message Andreas Karlsson 2013-07-17 02:16:00 Re: Listen/notify across clusters