Re: Package version in PG_VERSION and version()

2018-01-19 Thread Christoph Berg
Re: Peter Eisentraut 2018-01-17 > On 1/17/18 10:14, Christoph Berg wrote: > > The difference is that when parsing version() (which is all my variant > > is changing), people already have to deal with extra stuff at the end > > (gcc version),

Re: Package version in PG_VERSION and version()

2018-01-17 Thread Peter Eisentraut
On 1/17/18 10:14, Christoph Berg wrote: > The difference is that when parsing version() (which is all my variant > is changing), people already have to deal with extra stuff at the end > (gcc version), while that would be new for "psql --version". For me, having the package identifier in "psql

Re: Package version in PG_VERSION and version()

2018-01-17 Thread Christoph Berg
Re: Tom Lane 2018-01-17 <16522.1516201...@sss.pgh.pa.us> > I wrote: > > Yeah, but the same argument could be made against the variant > > you're proposing. In theory, people could have written arbitrarily > > brittle checks of version numbers/strings. I'm not exactly convinced > > that it's your

Re: Package version in PG_VERSION and version()

2018-01-17 Thread Tom Lane
I wrote: > Yeah, but the same argument could be made against the variant > you're proposing. In theory, people could have written arbitrarily > brittle checks of version numbers/strings. I'm not exactly convinced > that it's your (or our) problem if they did. BTW, as concrete evidence in this

Re: Package version in PG_VERSION and version()

2018-01-17 Thread Tom Lane
Christoph Berg writes: > Re: Tom Lane 2018-01-17 <15537.1516200...@sss.pgh.pa.us> >> IMO there's not really any evidence that we need an additional mechanism >> in this space. I don't see any way to get that evidence unless some >> packager tries to use the existing

Re: Package version in PG_VERSION and version()

2018-01-17 Thread Christoph Berg
Re: Tom Lane 2018-01-17 <15537.1516200...@sss.pgh.pa.us> > IMO there's not really any evidence that we need an additional mechanism > in this space. I don't see any way to get that evidence unless some > packager tries to use the existing mechanism and hits insurmountable > problems. The problem

Re: Package version in PG_VERSION and version()

2018-01-17 Thread Tom Lane
Christoph Berg writes: > Re: Peter Eisentraut 2018-01-17 > >> So what is the next action this thread? I think --with-extra-version is >> the right solution for packagers, so I'm tempted to close this commit >>

Re: Package version in PG_VERSION and version()

2018-01-17 Thread Christoph Berg
Re: Peter Eisentraut 2018-01-17 > So what is the next action this thread? I think --with-extra-version is > the right solution for packagers, so I'm tempted to close this commit > fest item. There is some speculation that using it could

Re: Package version in PG_VERSION and version()

2018-01-17 Thread Peter Eisentraut
On 1/3/18 10:25, Robert Haas wrote: > On Tue, Jan 2, 2018 at 9:20 PM, Craig Ringer wrote: >> Last time I tried to actually deploy packages that used --with-extra-version >> a variety of tools that talk to postgres broke because they choked when >> parsing the version.

Re: Package version in PG_VERSION and version()

2018-01-03 Thread Robert Haas
On Tue, Jan 2, 2018 at 9:20 PM, Craig Ringer wrote: > Last time I tried to actually deploy packages that used --with-extra-version > a variety of tools that talk to postgres broke because they choked when > parsing the version. Including widely used ones like

Re: Package version in PG_VERSION and version()

2018-01-02 Thread Craig Ringer
On 3 January 2018 at 00:53, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 12/15/17 06:53, Christoph Berg wrote: > >> Why reinventing the wheel when there is already --with-extra-version > >> that you can use for the same purpose? > > That modifies the PG version number as such,

Re: Package version in PG_VERSION and version()

2018-01-02 Thread Peter Eisentraut
On 12/15/17 06:53, Christoph Berg wrote: >> Why reinventing the wheel when there is already --with-extra-version >> that you can use for the same purpose? > That modifies the PG version number as such, as what psql is showing > on connect. I'd think that is too intrusive. > > And it doesn't work

Re: Package version in PG_VERSION and version()

2017-12-19 Thread Christoph Berg
Re: Robert Haas 2017-12-17 > Unfortunately, actually modifying the main version number breaks large > numbers of tools and drivers that think they know what a PostgreSQL > version number looks like, as many people who work for

Re: Package version in PG_VERSION and version()

2017-12-16 Thread Robert Haas
On Fri, Dec 15, 2017 at 10:23 AM, Tom Lane wrote: > Christoph Berg writes: >> Re: Michael Paquier 2017-12-15 >>

Re: Package version in PG_VERSION and version()

2017-12-15 Thread Christoph Berg
Re: Michael Paquier 2017-12-15

Re: Package version in PG_VERSION and version()

2017-12-15 Thread Michael Paquier
On Fri, Dec 15, 2017 at 7:46 PM, Christoph Berg wrote: > To be able to identify more easily which package a connected server is > coming from, I would like to embed the (Debian) package version in the > version() output which is coming from PG_VERSION. It is fairly