Re: Include commit identifier in version() function

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
Cc: pasman pasmański <pasman(dot)p(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Include commit identifier in version() function
Date: 2011-11-06 04:21:44
Message-ID: CA+TgmoZ3Qgxyv6SxLUCJEssjQH=L+Jdo3=xk414XnjBAGszJ5A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Nov 5, 2011 at 2:46 PM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
>> 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)

I wouldn't mind having it in my repository either, though I suspect it
would be of only occasional use to me in practice. I think your
parenthetical note hints at the real problem: right now, there's
nothing in our repository that knows anything about the repository
itself. To make something like this work, you'd have to know, for
example, that on Bruce's machine, the git you need to use is actually
called pggit, and is probably located at some pathname that would make
the gods of standardization cringe. Leaving aside the wisdom of such
configurations, upon which all sorts of doubt may be and has been
cast, they cause the rest of us no inconvenience right now, and doing
something like this would change that. Or you could ignore the git
executables and just look for a .git directory that you could read by
hand; but then you're at the mercy of any changes in the way that git
does things. Every way I can think of to do something like this would
fail in some situations in which everything now works.

I've taken to installing test builds on my machine under
$HOME/install/$IDENTIFIER, where $IDENTIFIER is a branch name or the
first 10 characters of a commit SHA. I've found that to be a pretty
handy solution to this problem. It still doesn't account for the
possibility that different builds were done with different options,
but at least I know what source code I was building from (the tip of
branch X as of whenever I did the install, or that specific commit).

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeroen Vermeulen 2011-11-06 07:16:08 Re: Multiple queries in transit
Previous Message Tomas Vondra 2011-11-06 03:42:20 Re: [PATCH] optional cleaning queries stored in pg_stat_statements