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),
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: 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
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
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: 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
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: 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
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.
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
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,
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: 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
On Fri, Dec 15, 2017 at 10:23 AM, Tom Lane wrote:
> Christoph Berg writes:
>> Re: Michael Paquier 2017-12-15
>>
Re: Michael Paquier 2017-12-15
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
16 matches
Mail list logo