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), while that would be new for "psql --version".
>
> For
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 -ve
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 ar
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 mechanism and hits insurmounta
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
>> fest item. There is some speculation that using it could break
>> third-party tools,
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 break
> third-party tools, but (a) we would need more conc
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. Including widely used ones li
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 check_postgres.
I think there's likel
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 a
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 my employer can
> testify to from personal experience with a piece of
On Fri, Dec 15, 2017 at 10:23 AM, Tom Lane wrote:
> Christoph Berg writes:
>> Re: Michael Paquier 2017-12-15
>>
>>> 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 s
Christoph Berg writes:
> Re: Michael Paquier 2017-12-15
>
>> 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.
I'm
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
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 easy to
> do that, but it requir
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 easy to
do that, but it requires patching configure(.in):
$ ./configure VENDOR_VERSION="Debia
18 matches
Mail list logo
