Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()

Neha Khatri writes: > On Fri, May 12, 2017 at 12:56 AM, Tom Lane wrote: >> Neha Khatri writes: >>> Following are pg_controldata interfaces that might require change: >>> Latest checkpoint location: >>> Prior checkpoint location:

Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()

On Fri, May 12, 2017 at 12:56 AM, Tom Lane wrote: > Neha Khatri writes: > > [In case forgotten] pg_controdata and pg_waldump interfaces should also > be > > considered for this standardization. > > > Following are pg_controldata interfaces that might

Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()

Neha Khatri writes: > [In case forgotten] pg_controdata and pg_waldump interfaces should also be > considered for this standardization. > Following are pg_controldata interfaces that might require change: > Latest checkpoint location: > Prior checkpoint location: >

Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()

Michael Paquier writes: > On Thu, May 11, 2017 at 9:15 AM, Bruce Momjian wrote: >> On Wed, May 10, 2017 at 01:09:36PM -0700, Joe Conway wrote: > On 05/10/2017 12:22 PM, Tom Lane wrote: >>> Hm, well, anybody else want to vote? >>> +1 for #2 >> Same,

Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()

On Thu, May 11, 2017 at 9:15 AM, Bruce Momjian wrote: > On Wed, May 10, 2017 at 01:09:36PM -0700, Joe Conway wrote: >> On 05/10/2017 12:22 PM, Tom Lane wrote: >> > Robert Haas writes: >> >> On Wed, May 10, 2017 at 1:13 PM, Tom Lane

Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()

On Wed, May 10, 2017 at 01:09:36PM -0700, Joe Conway wrote: > On 05/10/2017 12:22 PM, Tom Lane wrote: > > Robert Haas writes: > >> On Wed, May 10, 2017 at 1:13 PM, Tom Lane wrote: > >>> In terms of the alternatives I listed previously, it seems like >

Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()

On 10/05/17 21:22, Tom Lane wrote: > Robert Haas writes: >> On Wed, May 10, 2017 at 1:13 PM, Tom Lane wrote: >>> In terms of the alternatives I listed previously, it seems like >>> nobody liked alternatives #3, #4, or #5, leaving us with #1 (do >>>

Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()

On 05/10/2017 12:22 PM, Tom Lane wrote: > Robert Haas writes: >> On Wed, May 10, 2017 at 1:13 PM, Tom Lane wrote: >>> In terms of the alternatives I listed previously, it seems like >>> nobody liked alternatives #3, #4, or #5, leaving us with #1 (do >>>

Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()

Robert Haas writes: > On Wed, May 10, 2017 at 1:13 PM, Tom Lane wrote: >> In terms of the alternatives I listed previously, it seems like >> nobody liked alternatives #3, #4, or #5, leaving us with #1 (do >> nothing) or #2 (apply this patch). By my

Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()

On Wed, May 10, 2017 at 1:13 PM, Tom Lane wrote: > David Steele writes: >> If I read this correctly, we won't change the names of any functions >> that we haven't *already* changed the names of, and only one view would >> be changed to bring it into line

Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()

David Steele writes: > If I read this correctly, we won't change the names of any functions > that we haven't *already* changed the names of, and only one view would > be changed to bring it into line with the rest. I have now looked through the patch more carefully, and

Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()

On 5/9/17 10:00 AM, Stephen Frost wrote: * Tom Lane (t...@sss.pgh.pa.us) wrote: #2: Rename all these functions and columns to "lsn", as in this patch. +1 <...> #2 strikes me as the best option, though that's probably not much of a surprise to anyone whose been following my comments on

Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()

Tom, all, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Peter Eisentraut writes: > > On 5/1/17 08:10, David Rowley wrote: > >> OK, so I've created a draft patch which does this. > > > After reading this patch, I see that > > a) The scope of the compatibility break

Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()

Peter Eisentraut writes: > On 5/1/17 08:10, David Rowley wrote: >> OK, so I've created a draft patch which does this. > After reading this patch, I see that > a) The scope of the compatibility break is expanded significantly beyond > what was already affected by

Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()

On 5/1/17 08:10, David Rowley wrote: > On 20 April 2017 at 07:29, Euler Taveira wrote: >> 2017-04-19 1:32 GMT-03:00 Michael Paquier : >>> >>> I vote for "location" -> "lsn". I would expect complains about the >>> current inconsistency at some

Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()

On Sat, May 6, 2017 at 4:09 PM, Tom Lane wrote: > Noah Misch writes: > > On Fri, May 05, 2017 at 03:36:39AM +1200, David Rowley wrote: > >> Do any of the committers who voted for this change feel inclined to > >> pick this patch up? > > > I'll echo that

Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()

Noah Misch writes: > On Fri, May 05, 2017 at 03:36:39AM +1200, David Rowley wrote: >> Do any of the committers who voted for this change feel inclined to >> pick this patch up? > I'll echo that question. This open item lacks a clear owner. One might argue > that 806091c

Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()

On Fri, May 05, 2017 at 03:36:39AM +1200, David Rowley wrote: > On 2 May 2017 at 00:10, David Rowley wrote: > > On 20 April 2017 at 07:29, Euler Taveira wrote: > >> 2017-04-19 1:32 GMT-03:00 Michael Paquier : > >>> >

Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()

On 2 May 2017 at 00:10, David Rowley wrote: > On 20 April 2017 at 07:29, Euler Taveira wrote: >> 2017-04-19 1:32 GMT-03:00 Michael Paquier : >>> >>> I vote for "location" -> "lsn". I would expect complains about the

Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()

On 20 April 2017 at 07:29, Euler Taveira wrote: > 2017-04-19 1:32 GMT-03:00 Michael Paquier : >> >> I vote for "location" -> "lsn". I would expect complains about the >> current inconsistency at some point, and the function names have been >>

Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()

2017-04-19 1:32 GMT-03:00 Michael Paquier : > I vote for "location" -> "lsn". I would expect complains about the > current inconsistency at some point, and the function names have been > already changed for this release.. > +1. -- Euler Taveira

Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()

At Wed, 19 Apr 2017 13:32:48 +0900, Michael Paquier wrote in

Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()

On Wed, Apr 19, 2017 at 12:36 PM, David Rowley wrote: > In favour of "location" -> "lsn": Tom, Stephen, David Steel > In favour of "lsn" -> "location": Peter, Kyotaro I vote for "location" -> "lsn". I would expect complains about the current inconsistency at some

Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()

On 19 April 2017 at 15:31, Tom Lane wrote: > David Rowley writes: >> OK, so I've read over this thread again and I think it's time to >> summarise the votes: >> ... >> In favour of "location" -> "lsn": Stephen, David Steel, >> In favour of "lsn"

Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()

David Rowley writes: > OK, so I've read over this thread again and I think it's time to > summarise the votes: > ... > In favour of "location" -> "lsn": Stephen, David Steel, > In favour of "lsn" -> "location": Peter, Tom, Kyotaro FWIW, I was not voting in favor of

Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()

On 19 April 2017 at 03:33, David Steele wrote: > +1, and I'm in favor of using "lsn" wherever applicable. It seems to me > that if a user calls a function (or queries a table) that returns an lsn > then they should be aware of what an lsn is. OK, so I've read over this

Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()

On 4/15/17 12:56 PM, Robert Haas wrote: > On Fri, Apr 14, 2017 at 6:52 PM, Tom Lane wrote: >> Peter Eisentraut writes: >>> If we're talking about making things easier to understand, wouldn't a >>> random user rather know what a WAL "location"

Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()

At Sat, 15 Apr 2017 12:56:32 -0400, Robert Haas wrote in > On Fri, Apr 14, 2017 at 6:52 PM, Tom Lane wrote: > > Peter Eisentraut writes: > >> If

Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()

At Fri, 14 Apr 2017 18:26:37 -0400, Peter Eisentraut wrote in <052f4ce0-159a-1666-f136-91977d326...@2ndquadrant.com> > On 4/14/17 04:28, Kyotaro HORIGUCHI wrote: > > =# select distinct attname from pg_attribute where attname like '%lsn%'; > >attname

Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()

On Fri, Apr 14, 2017 at 6:52 PM, Tom Lane wrote: > Peter Eisentraut writes: >> If we're talking about making things easier to understand, wouldn't a >> random user rather know what a WAL "location" is instead of a WAL "LSN"? > > I wouldn't

Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()

Peter Eisentraut writes: > If we're talking about making things easier to understand, wouldn't a > random user rather know what a WAL "location" is instead of a WAL "LSN"? I wouldn't object to standardizing on "location" instead of "lsn" in the related function

Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()

On 4/14/17 11:36, Bruce Momjian wrote: > Yeah, this area is complex enough so any consistency we can add helps. If we're talking about making things easier to understand, wouldn't a random user rather know what a WAL "location" is instead of a WAL "LSN"? -- Peter Eisentraut

Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()

On 4/14/17 04:28, Kyotaro HORIGUCHI wrote: > =# select distinct attname from pg_attribute where attname like '%lsn%'; >attname > - > confirmed_flush_lsn > latest_end_lsn > local_lsn > receive_start_lsn > received_lsn > remote_lsn > restart_lsn > srsublsn

Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Robert Haas writes: > > On Fri, Apr 14, 2017 at 4:28 AM, Kyotaro HORIGUCHI > > wrote: > >> Similariliy, these columns may need renaming. > > > Personally, I would be inclined not to tinker with

Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()

On Fri, Apr 14, 2017 at 10:22:36AM -0400, Tom Lane wrote: > Robert Haas writes: > > On Fri, Apr 14, 2017 at 4:28 AM, Kyotaro HORIGUCHI > > wrote: > >> Similariliy, these columns may need renaming. > > > Personally, I would be inclined not

Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()

Robert Haas writes: > On Fri, Apr 14, 2017 at 4:28 AM, Kyotaro HORIGUCHI > wrote: >> Similariliy, these columns may need renaming. > Personally, I would be inclined not to tinker with this, not just > because we're after freeze but because

Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()

On Fri, Apr 14, 2017 at 4:28 AM, Kyotaro HORIGUCHI wrote: > Similariliy, these columns may need renaming. > > s=# select attname, attrelid::regclass from pg_attribute where attname like > '%location%'; > attname | attrelid >

Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()

At Mon, 10 Apr 2017 19:26:11 +1200, David Rowley wrote in > ... and of course the other functions matching *wal*location* > > My thoughts here are that we're already breaking backward >

[HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()

... and of course the other functions matching *wal*location* My thoughts here are that we're already breaking backward compatibility of these functions for PG10, so thought we might want to use this as an opportunity to fix the naming a bit more. I feel that the "location" word not the best