I wrote:
> I've pushed this with minor additional twiddling. We can work on the
> "UI issues" you mentioned at leisure. One that I noted is that psql's
> version-mismatch-warning messages aren't two-part-version aware, and
> will print "10.0" where they should say "10". Probably that fix should
Peter Eisentraut writes:
> On 8/1/16 11:49 AM, Tom Lane wrote:
>> Somebody needs to come up with a patch implementing this changeover.
> Here is such a patch. It does not yet implement:
I've pushed this with minor additional twiddling. We can work on the
"UI issues" you mentioned at leisure.
Peter Eisentraut writes:
> One hiccup I found is that server_version_num is not sent to clients.
> Instead, libpq assembles the numeric version number itself from the
> string version, and it will fail if it sees only one number (e.g.,
> 10devel). It will then set the version number to 0 for "unk
On 5 August 2016 at 04:31, Tom Lane wrote:
> In short: if we'd done it that way all along, it would've been nice.
But encouraging people to change horses now isn't really going to
> make things better. What is far more likely to happen, if we were
> to do that, is that people will make client
On 08/01/2016 04:25 PM, Tom Lane wrote:
Andrew Dunstan writes:
Somewhat related is how we name the git branches. It would help me from
a buildfarm POV if we kept lexically them sortable, which could be done
at least for the next 90 major releases :-) by adding an underscore
after the REL piec
Peter Eisentraut writes:
> On 8/3/16 1:20 PM, Tom Lane wrote:
>> I was just wondering whether it would be worth starting to use "git tag -a".
> One should always use annotated tags for public releases. That way, the
> tag is its own Git object that cannot be later moved around or easily
> faked
Robert Haas writes:
> On Thu, Aug 4, 2016 at 9:57 AM, Tom Lane wrote:
>> [ shrug... ] What do you claim is not machine-readable about
>> server_version?
> Surely you can't have missed the connection between the issue at hand
> and what Craig is talking about. If libpq were using the
> machine-
On Thu, Aug 4, 2016 at 9:57 AM, Tom Lane wrote:
> Vladimir Sitnikov writes:
>>> Sorry, but I don't buy that. I think sending both server_version and
>>> server_version_num would be silly, and we're certainly not going to stop
>>> sending server_version.
>
>> What is wrong with sending machine-re
On 8/3/16 1:20 PM, Tom Lane wrote:
> I was just wondering whether it would be worth starting to use "git tag -a".
One should always use annotated tags for public releases. That way, the
tag is its own Git object that cannot be later moved around or easily
faked (modulo GPG signatures -- a whole d
Tom Lane :
> [ shrug... ] What do you claim is not machine-readable about
> server_version?
>
0) server_version needs a dance to parse.
For instance, recent "Stamp version 10devel" patch did touch
"server_version" parsing in fe-exec.c:
https://github.com/vlsi/postgres/pull/2/files#diff-2df5cad06
Vladimir Sitnikov writes:
>> Sorry, but I don't buy that. I think sending both server_version and
>> server_version_num would be silly, and we're certainly not going to stop
>> sending server_version.
> What is wrong with sending machine-readable value?
[ shrug... ] What do you claim is not ma
>
> Sorry, but I don't buy that. I think sending both server_version and
> server_version_num would be silly, and we're certainly not going to stop
> sending server_version.
>
What is wrong with sending machine-readable value?
Vladimir
Craig Ringer writes:
> On 4 August 2016 at 12:45, Tom Lane wrote:
>> Craig Ringer writes:
>>> Well, this seems like a good time to make server_version_num GUC_REPORT
>>> as well...
>> To what end? Existing versions of libpq wouldn't know about it, and new
>> versions of libpq couldn't rely on
On 4 August 2016 at 12:45, Tom Lane wrote:
> Craig Ringer writes:
> > On 4 August 2016 at 02:15, Tom Lane wrote:
> >> So it seems like fixing libpq's parsing of server_version_num is
> >> something we definitely want to fix ASAP in all back branches.
>
> > Well, this seems like a good time to m
Craig Ringer writes:
> On 4 August 2016 at 02:15, Tom Lane wrote:
>> So it seems like fixing libpq's parsing of server_version_num is
>> something we definitely want to fix ASAP in all back branches.
> Well, this seems like a good time to make server_version_num GUC_REPORT as
> well...
To what
On 4 August 2016 at 02:15, Tom Lane wrote:
> Robert Haas writes:
> > On Wed, Aug 3, 2016 at 12:12 PM, Peter Eisentraut
> > wrote:
> >> One hiccup I found is that server_version_num is not sent to clients.
> >> Instead, libpq assembles the numeric version number itself from the
> >> string versi
Robert Haas writes:
> On Wed, Aug 3, 2016 at 12:12 PM, Peter Eisentraut
> wrote:
>> One hiccup I found is that server_version_num is not sent to clients.
>> Instead, libpq assembles the numeric version number itself from the
>> string version, and it will fail if it sees only one number (e.g.,
>>
On Wed, Aug 3, 2016 at 12:12 PM, Peter Eisentraut
wrote:
> One hiccup I found is that server_version_num is not sent to clients.
> Instead, libpq assembles the numeric version number itself from the
> string version, and it will fail if it sees only one number (e.g.,
> 10devel). It will then set
On Wed, Aug 3, 2016 at 1:20 PM, Tom Lane wrote:
> Greg Stark writes:
> > Right now git-describe --tags on a random revision between 9.4
> > and 9.5 will print something like REL9_4_BETA1-1973-g85c25fd or
> > something like REL9_5_BETA2-33-g55a2cc8 if it happens to be after a
> > beta. It's reall
Greg Stark writes:
> It would also be nice to have a tag or branch name for the development
> branch.
Uh, the branch name is "master". I doubt we want to change that.
And you can't really have a tag on a branch, AFAIK --- a tag names
a specific commit and can't ever be moved. I think the fundam
On Wed, Aug 3, 2016 at 5:27 PM, Tom Lane wrote:
> Well, the rule would be that "REL_xx" is a branch, "REL_xx_yy" is a
> release tag. Neither of these is confusable with old-style
> branch or tag names. The alternative seems to be saying that
> "REL_xx_STABLE" is a branch while "REL_xx_yy" is a r
On Wed, Aug 3, 2016 at 12:51 PM, Greg Stark wrote:
> On Tue, Aug 2, 2016 at 2:57 PM, Tom Lane wrote:
> > I thought we'd pretty much done that cleanup during the cvs->git
> > conversion?
>
> I guess I'm talking about tags. I'm not clear on the distinction
> between tags and branches names in git.
Greg Stark writes:
> On Tue, Aug 2, 2016 at 2:57 PM, Tom Lane wrote:
>> I thought we'd pretty much done that cleanup during the cvs->git
>> conversion?
> I guess I'm talking about tags. I'm not clear on the distinction
> between tags and branches names in git.
> Prior to 8.0.0 we seem to have t
On Tue, Aug 2, 2016 at 2:57 PM, Tom Lane wrote:
> I thought we'd pretty much done that cleanup during the cvs->git
> conversion?
I guess I'm talking about tags. I'm not clear on the distinction
between tags and branches names in git.
Prior to 8.0.0 we seem to have tagged the first release with a
Peter Eisentraut writes:
> On 8/1/16 9:10 PM, Alvaro Herrera wrote:
>> I don't see any value to the _STABLE
>> suffix, given the way we treat branches.
> It would be nice to be able to tell easily from convention whether
> something is a branch or a tag.
Well, the rule would be that "REL_xx" is
On 8/1/16 11:49 AM, Tom Lane wrote:
> Somebody needs to come up with a patch implementing this changeover.
Here is such a patch. It does not yet implement:
> (External code will need some cue as
> to how to format displays from PG_VERSION_NUM, so we should have a hard
> and fast rule that major
On 8/1/16 9:10 PM, Alvaro Herrera wrote:
> I don't see any value to the _STABLE
> suffix, given the way we treat branches.
It would be nice to be able to tell easily from convention whether
something is a branch or a tag.
Anyway, this is a question for many months from now.
--
Peter Eisentraut
Greg Stark writes:
> On Tue, Aug 2, 2016 at 2:10 AM, Alvaro Herrera
> wrote:
>> That said, I'm not opposed to REL_10 and so on. In 89 years there will
>> be a problem with sorting REL_100 but I'm sure they can find a solution
>> then, if computers still need humans to write programs for them.
On Tue, Aug 2, 2016 at 2:10 AM, Alvaro Herrera wrote:
> That said, I'm not opposed to REL_10 and so on. In 89 years there will
> be a problem with sorting REL_100 but I'm sure they can find a solution
> then, if computers still need humans to write programs for them.
It would be nice if there wa
Michael Paquier wrote:
> On Tue, Aug 2, 2016 at 5:25 AM, Tom Lane wrote:
> > Andrew Dunstan writes:
> >> Somewhat related is how we name the git branches. It would help me from
> >> a buildfarm POV if we kept lexically them sortable, which could be done
> >> at least for the next 90 major release
On Tue, Aug 2, 2016 at 5:25 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>> Somewhat related is how we name the git branches. It would help me from
>> a buildfarm POV if we kept lexically them sortable, which could be done
>> at least for the next 90 major releases :-) by adding an underscore
>>
Andrew Dunstan writes:
> Somewhat related is how we name the git branches. It would help me from
> a buildfarm POV if we kept lexically them sortable, which could be done
> at least for the next 90 major releases :-) by adding an underscore
> after the REL piece, thus: REL_10_STABLE. I realise
On 08/01/2016 11:49 AM, Tom Lane wrote:
Also, it strikes me that we need a new convention for how we talk about
release branches informally. Up to now, mentioning say "9.5" without
any further qualification in a PG-list message was usually sufficient
to indicate a branch number, but I do not
David,
* David Fetter (da...@fetter.org) wrote:
> On Mon, Aug 01, 2016 at 02:52:04PM -0400, Stephen Frost wrote:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > > "David G. Johnston" writes:
> > > > I suspect I'll end up using 10.x somewhat frequently though I'm mostly
> > > > on
> > > > the list
On Mon, Aug 01, 2016 at 02:52:04PM -0400, Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > "David G. Johnston" writes:
> > > I suspect I'll end up using 10.x somewhat frequently though I'm mostly on
> > > the lists. I suspect the choice will be dependent on context and channel.
>
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> "David G. Johnston" writes:
> > I suspect I'll end up using 10.x somewhat frequently though I'm mostly on
> > the lists. I suspect the choice will be dependent on context and channel.
>
> Hmm, that seems like a workable answer as well, and one that's trac
"David G. Johnston" writes:
> I suspect I'll end up using 10.x somewhat frequently though I'm mostly on
> the lists. I suspect the choice will be dependent on context and channel.
Hmm, that seems like a workable answer as well, and one that's traceable
to our past habits.
On Mon, Aug 1, 2016 at 1:41 PM, Tom Lane wrote:
> Over the past couple of months I have already found myself
> writing "10.0" or "9.7^H^H^H10" to make it clear that I meant the next
> release version, because just "10" seemed too ambiguous.
I thought that was just (and maybe some instances wer
David Fetter writes:
> On Mon, Aug 01, 2016 at 11:49:41AM -0400, Tom Lane wrote:
>> Also, it strikes me that we need a new convention for how we talk about
>> release branches informally. Up to now, mentioning say "9.5" without
>> any further qualification in a PG-list message was usually suffici
Tom Lane wrote:
> Also, it strikes me that we need a new convention for how we talk about
> release branches informally. Up to now, mentioning say "9.5" without
> any further qualification in a PG-list message was usually sufficient
> to indicate a branch number, but I do not think that will work
On Mon, Aug 01, 2016 at 11:49:41AM -0400, Tom Lane wrote:
> As Peter mentioned in
> https://www.postgresql.org/message-id/ba76aeb0-2f84-d180-268f-ea0f5ace4...@2ndquadrant.com
> the decision has been taken to simplify our user-facing version numbering
> system to be a two-component number. Since th
As Peter mentioned in
https://www.postgresql.org/message-id/ba76aeb0-2f84-d180-268f-ea0f5ace4...@2ndquadrant.com
the decision has been taken to simplify our user-facing version numbering
system to be a two-component number. Since there have been questions
about the details of that, I wanted to emp
42 matches
Mail list logo
