* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> On 1/12/17 1:40 PM, Stephen Frost wrote:
> > I just don't buy this argument, at all. These functions names are
> > certainly not the only things we're changing with PG10 and serious
> > monitoring/backup/administration tools are
On 1/12/17 2:22 PM, Stephen Frost wrote:
> The point I was making above is that the only reason to not make such
> changes is if they really are entirely arbitrary, but I don't think
> we'd even be having this discussion if that was the case or that we'd
> be split about the question. We already
On 1/12/17 1:50 PM, Stephen Frost wrote:
> When they're changes that are primairly going to affect
> monitoring/backup/administration tools, yes, I do think we can make just
> about arbitrary backward-incompatible changes.
I don't agree with that.
--
Peter Eisentraut
On 1/12/17 1:40 PM, Stephen Frost wrote:
> I just don't buy this argument, at all. These functions names are
> certainly not the only things we're changing with PG10 and serious
> monitoring/backup/administration tools are almost certainly going to
> have quite a bit to adjust to with the new
Andres,
* Andres Freund (and...@anarazel.de) wrote:
> On January 12, 2017 10:50:18 AM PST, Stephen Frost wrote:
> >* Andres Freund (and...@anarazel.de) wrote:
> >> On 2017-01-12 13:40:50 -0500, Stephen Frost wrote:
> >> > * Jim Nasby (jim.na...@bluetreble.com) wrote:
> >> > >
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > I just don't buy this argument, at all. These functions names are
> > certainly not the only things we're changing with PG10 and serious
> > monitoring/backup/administration tools are almost certainly going to
On January 12, 2017 10:50:18 AM PST, Stephen Frost wrote:
>* Andres Freund (and...@anarazel.de) wrote:
>> On 2017-01-12 13:40:50 -0500, Stephen Frost wrote:
>> > * Jim Nasby (jim.na...@bluetreble.com) wrote:
>> > > The way I see it, either one person can spend an hour or
* Andres Freund (and...@anarazel.de) wrote:
> On 2017-01-12 13:40:50 -0500, Stephen Frost wrote:
> > * Jim Nasby (jim.na...@bluetreble.com) wrote:
> > > The way I see it, either one person can spend an hour or whatever
> > > creating an extension once, or every postgres install that's using
> > >
Stephen Frost writes:
> I just don't buy this argument, at all. These functions names are
> certainly not the only things we're changing with PG10 and serious
> monitoring/backup/administration tools are almost certainly going to
> have quite a bit to adjust to with the new
On 2017-01-12 13:40:50 -0500, Stephen Frost wrote:
> Jim,
>
> * Jim Nasby (jim.na...@bluetreble.com) wrote:
> > The way I see it, either one person can spend an hour or whatever
> > creating an extension once, or every postgres install that's using
> > any of these functions now has yet another
Jim,
* Jim Nasby (jim.na...@bluetreble.com) wrote:
> The way I see it, either one person can spend an hour or whatever
> creating an extension once, or every postgres install that's using
> any of these functions now has yet another hurdle to upgrading.
I just don't buy this argument, at all.
On Thu, Jan 12, 2017 at 12:12 PM, Tom Lane wrote:
> Vladimir Rusinov writes:
>> On Thu, Jan 12, 2017 at 4:57 PM, Euler Taveira wrote:
>>> As Robert suggested in the other email: extension to create old names.
>
>> I don't follow the
On 1/12/17 10:12 AM, Tom Lane wrote:
Yeah, I'm not terribly for the extension idea. Robert cited the precedent
of contrib/tsearch2, but I think the history of that is a good argument
against this: tsearch2 is still there 9 years later and there's no
indication that we'll ever get rid of it. We
Vladimir Rusinov writes:
> On Thu, Jan 12, 2017 at 4:57 PM, Euler Taveira wrote:
>> As Robert suggested in the other email: extension to create old names.
> I don't follow the reasoning for the extension. It seem to have downsides
> of both
On Thu, Jan 12, 2017 at 4:57 PM, Euler Taveira wrote:
> As Robert suggested in the other email: extension to create old names.
I don't follow the reasoning for the extension. It seem to have downsides
of both alternatives combined: we still break people's code, and we add
On 12-01-2017 10:56, David Steele wrote:
>> So, to sum up things on this thread, here are the votes about the use
>> of aliases or a pure breakage:
>> - No to aliases, shake the world: Stephen, Tom, David F, Vik, Bruce M => 5
>> - Yes to aliases: Michael P, Andres, Peter E., Cynthia S, Jim N,
>>
On Thu, Jan 12, 2017 at 5:49 AM, Michael Paquier
wrote:
> The patch still updates a bunch of .po files. Those are normally
> refreshed with the translation updates, so they had better be removed.
> Other than that, the patch looks in good shape to me so switch to
>
On Thu, Jan 12, 2017 at 8:56 AM, David Steele wrote:
>> So, to sum up things on this thread, here are the votes about the use
>> of aliases or a pure breakage:
>> - No to aliases, shake the world: Stephen, Tom, David F, Vik, Bruce M => 5
>> - Yes to aliases: Michael P,
On 1/12/17 12:49 AM, Michael Paquier wrote:
> On Thu, Jan 12, 2017 at 2:00 AM, Vladimir Rusinov wrote:
>> On Tue, Jan 10, 2017 at 5:24 AM, Michael Paquier
>> wrote:
>>> As there are two school of thoughts on this thread, keeping your patch
>>> with
On Thu, Jan 12, 2017 at 2:49 PM, Michael Paquier
wrote:
> On Thu, Jan 12, 2017 at 2:00 AM, Vladimir Rusinov wrote:
>> On Tue, Jan 10, 2017 at 5:24 AM, Michael Paquier
>> wrote:
>>> As there are two school of thoughts on
On Thu, Jan 12, 2017 at 2:00 AM, Vladimir Rusinov wrote:
> On Tue, Jan 10, 2017 at 5:24 AM, Michael Paquier
> wrote:
>> As there are two school of thoughts on this thread, keeping your patch
>> with the compatibility table is the best move for now.
On Tue, Jan 10, 2017 at 5:24 AM, Michael Paquier
wrote:
> -errhint("pg_xlogfile_name_offset() cannot be executed
> during recovery.")));
> +errhint(
> +"pg_wal_file_name_offset() cannot be executed
> during
On Wed, Jan 4, 2017 at 4:32 PM, Andres Freund wrote:
> Hi,
>
> On 2017-01-03 10:37:08 -0500, Stephen Frost wrote:
>> * Vladimir Rusinov (vrusi...@google.com) wrote:
>> > I think I +1 on this.
>> > I've did a github search on these function names and there is a lot of code
>> >
On Tue, Jan 10, 2017 at 1:53 AM, Vladimir Rusinov wrote:
>
> On Mon, Jan 9, 2017 at 4:14 PM, Peter Eisentraut
> wrote:
>>
>> > pg_is_xlog_replay_paused| pg_is_recovery_paused
>>
>> All the other xlog_replay names have been changed to
On Mon, Jan 9, 2017 at 4:14 PM, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> > pg_is_xlog_replay_paused| pg_is_recovery_paused
>
> All the other xlog_replay names have been changed to wal_replay, so
> making this one different is probably not so good.
>
Oops, forgot
On 1/9/17 10:50 AM, Vladimir Rusinov wrote:
> pg_is_xlog_replay_paused| pg_is_recovery_paused
All the other xlog_replay names have been changed to wal_replay, so
making this one different is probably not so good.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL
On Fri, Jan 6, 2017 at 12:44 AM, Michael Paquier
wrote:
> > - OIDs - where do I get numbers from? I was kinda choosing them at
> random,
> > unaware if there is some process for keeping track of them. Please point
> me
> > if such thing exists and I'll change them.
>
>
On 1/6/17 7:21 PM, Bruce Momjian wrote:
I don't think anyone is arguing that these API breakages are cost-free,
but I think long-term, the costs are minor compared to the clean API we
provide to users.
Except in this case we can provide a clean new API without gratuitously
breaking the old
On Wed, Jan 4, 2017 at 09:38:42AM -0500, Stephen Frost wrote:
> > I think we've been far to cavalier lately about unnecessarily breaking
> > admin and monitoring tools. There's been pg_stat_activity backward
> > incompat changes in most of the last releases. It's a *PAIN* to develop
> >
On Fri, Jan 6, 2017 at 1:31 AM, Vladimir Rusinov wrote:
> Attaching a patch that renames all 'xlog' functions, keeping aliases for old
> ones (since it looks like majority vote is for keeping them).
OK.
> - OIDs - where do I get numbers from? I was kinda choosing them at
Andres,
* Andres Freund (and...@anarazel.de) wrote:
> On 2017-01-04 09:38:42 -0500, Stephen Frost wrote:
> > * Andres Freund (and...@anarazel.de) wrote:
> > > On 2017-01-03 10:37:08 -0500, Stephen Frost wrote:
> > > > * Vladimir Rusinov (vrusi...@google.com) wrote:
> > > > > I think I +1 on this.
On 2017-01-04 09:38:42 -0500, Stephen Frost wrote:
> Andres,
>
> * Andres Freund (and...@anarazel.de) wrote:
> > On 2017-01-03 10:37:08 -0500, Stephen Frost wrote:
> > > * Vladimir Rusinov (vrusi...@google.com) wrote:
> > > > I think I +1 on this.
> > > > I've did a github search on these
Attaching a patch that renames all 'xlog' functions, keeping aliases for
old ones (since it looks like majority vote is for keeping them).
Following functions have been renamed:
Name| Replaced by
Stephen Frost writes:
> As I said in what you did quote above- I won't complain if someone wants
> the aliases and we include them in the documentation, but I don't agree
> with the other suggestions of having undocumented aliases or not making
> the change.
FWIW, that
Andres,
* Andres Freund (and...@anarazel.de) wrote:
> On 2017-01-03 10:37:08 -0500, Stephen Frost wrote:
> > * Vladimir Rusinov (vrusi...@google.com) wrote:
> > > I think I +1 on this.
> > > I've did a github search on these function names and there is a lot of
> > > code
> > > that use them.
On 4 January 2017 at 07:32, Andres Freund wrote:
> I think we've been far to cavalier lately about unnecessarily breaking
> admin and monitoring tools.
> Just renaming well known functions for a minor bit of
> cleanliness seems not to survive a cost/benefit analysis.
+1
Hi,
On 2017-01-03 10:37:08 -0500, Stephen Frost wrote:
> * Vladimir Rusinov (vrusi...@google.com) wrote:
> > I think I +1 on this.
> > I've did a github search on these function names and there is a lot of code
> > that use them. E.g. there is 8.5k hits for pg_last_xlog_location
> >
* Vladimir Rusinov (vrusi...@google.com) wrote:
> On Tue, Jan 3, 2017 at 3:37 PM, Stephen Frost wrote:
> > If they're maintained, then they'll be updated. I don't have any
> >
> sympathy if they aren't maintained.
> >
>
> Updating may be non-trivial effort even if they are
On Tue, Jan 3, 2017 at 3:37 PM, Stephen Frost wrote:
> If they're maintained, then they'll be updated. I don't have any
>
sympathy if they aren't maintained.
>
Updating may be non-trivial effort even if they are maintained. E.g. some
project may need to support both 9.6 and
Vladamir, all,
* Vladimir Rusinov (vrusi...@google.com) wrote:
> On Tue, Jan 3, 2017 at 11:56 AM, Michael Paquier
> wrote:
>
> > Yeah, let's make the life of users just easier if we can, without any
> > extension. Some people are likely going to forget to enable it
On Tue, Jan 3, 2017 at 11:56 AM, Michael Paquier
wrote:
> Yeah, let's make the life of users just easier if we can, without any
> extension. Some people are likely going to forget to enable it anyway,
> and some more don't like installing the package dedicated to
On Tue, Jan 3, 2017 at 4:18 AM, Tom Lane wrote:
> I'm also -1 on this idea. If we're going to provide backwards
> compatibility, we should just leave the old names in the core.
> Providing an extension is more work for *everybody* --- for us, and
> for the users who will have
Jim Nasby writes:
> On 1/2/17 11:39 AM, David Steele wrote:
>> On 1/2/17 12:30 PM, Jim Nasby wrote:
>>> On 1/1/17 9:48 AM, Peter Eisentraut wrote:
>>> Perhaps we should split the difference and do what we did for XML:
>>> provide a contrib module with alias functions
On 1/2/17 11:39 AM, David Steele wrote:
On 1/2/17 12:30 PM, Jim Nasby wrote:
On 1/1/17 9:48 AM, Peter Eisentraut wrote:
On 12/30/16 9:57 AM, Stephen Frost wrote:
Additionally, people who are actually using these bits of the system are
almost certainly going to have to adjust things for the
On 1/2/17 12:30 PM, Jim Nasby wrote:
> On 1/1/17 9:48 AM, Peter Eisentraut wrote:
>> On 12/30/16 9:57 AM, Stephen Frost wrote:
>>> Additionally, people who are actually using these bits of the system are
>>> almost certainly going to have to adjust things for the directory
>>> change,
>>
>> Some
On 1/1/17 9:48 AM, Peter Eisentraut wrote:
On 12/30/16 9:57 AM, Stephen Frost wrote:
Additionally, people who are actually using these bits of the system are
almost certainly going to have to adjust things for the directory
change,
Some *xlog* functions are commonly used to measure replay
On 12/30/16 9:57 AM, Stephen Frost wrote:
> Additionally, people who are actually using these bits of the system are
> almost certainly going to have to adjust things for the directory
> change,
Some *xlog* functions are commonly used to measure replay lag. That
usage would not be affected by
On 12/30/2016 06:46 PM, David Fetter wrote:
> On Fri, Dec 30, 2016 at 09:57:25AM -0500, Stephen Frost wrote:
>
>> Let's make this a clean break/change.
>
> +1
+1
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise,
On Fri, Dec 30, 2016 at 09:57:25AM -0500, Stephen Frost wrote:
> Let's make this a clean break/change.
+1
If there are known management gizmos to notify, it'd be nice to try to
give them some sort of warning, but even for them, the release notes
should spell it out clearly.
That business
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> On Fri, Dec 30, 2016 at 8:08 PM, Vladimir Rusinov wrote:
> > Now, I'm not sure whether it is worth maintaining function aliases. Assuming
> > these are indeed trivial (can somebody point me to example?) I see roughly
> >
On Fri, Dec 30, 2016 at 8:08 PM, Vladimir Rusinov wrote:
> Now, I'm not sure whether it is worth maintaining function aliases. Assuming
> these are indeed trivial (can somebody point me to example?) I see roughly
> the same amount of downsides both ways.
> Having aliases
On Fri, Dec 30, 2016 at 2:59 AM, Stephen Frost wrote:
> All backwards incompatible changes are judgement calls and people are
> certainly welcome to have different opinions. I have a pretty strong
> feeling about this particular change being worthwhile and also pretty
> long
On Thu, Dec 29, 2016 at 5:59 PM, Stephen Frost wrote:
> I have a pretty strong
> feeling about this particular change being worthwhile and also pretty
> long overdue.
>
Yeah, sorry for that. I should be able to make some progress early January.
--
Vladimir Rusinov
Storage
On Thu, Dec 29, 2016 at 5:48 PM, Cynthia Shang <
cynthia.sh...@crunchydata.com> wrote:
> I have never heard of coding standards where naming conventions required a
> function/variable name match a directory or file name. It seems that would
> be restrictive.
>
This is not about coding standard,
Cynthia,
Please don't top-post on the PG mailing lists but rather write responses
in-line.
* Cynthia Shang (cynthia.sh...@crunchydata.com) wrote:
> I have never heard of coding standards where naming conventions required a
> function/variable name match a directory or file name. It seems that
I have never heard of coding standards where naming conventions required a
function/variable name match a directory or file name. It seems that would be
restrictive.
I'm not trying to pick a fight, I just think the pros should outweigh the cons
when choosing a path forward. In this case I see
Cynthia,
* Cynthia Shang (cynthia.sh...@crunchydata.com) wrote:
> 1) I agree with Michael that we should make this change backward compatible.
> It would help PostgreSQL image if we did not break everyone's code. It costs
> businesses money to rewrite code (e.g. middle tier software, backup
1) I agree with Michael that we should make this change backward compatible. It
would help PostgreSQL image if we did not break everyone's code. It costs
businesses money to rewrite code (e.g. middle tier software, backup tools,
etc), test and redeploy to their customers.
2) We decided to
On Thu, Dec 15, 2016 at 8:51 AM, Michael Paquier
wrote:
> On Thu, Dec 15, 2016 at 1:20 AM, Vladimir Rusinov wrote:
>>> Personally, I think this is not important, but if you want to do it, I'd
>>> follow the suggestion in the thread to rename all
On Wed, Dec 14, 2016 at 11:51 PM, Michael Paquier wrote:
> > On Wed, Dec 14, 2016 at 4:07 PM, Peter Eisentraut
> > wrote:
> > Others will follow later in separate patches. Or is it preferred to have
> one
> > huge patch submitted?
>
On Thu, Dec 15, 2016 at 1:20 AM, Vladimir Rusinov wrote:
>
> On Wed, Dec 14, 2016 at 4:07 PM, Peter Eisentraut
> wrote:
> Others will follow later in separate patches. Or is it preferred to have one
> huge patch submitted?
Please yes. One
On Wed, Dec 14, 2016 at 4:07 PM, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 12/13/16 12:47 PM, Vladimir Rusinov wrote:
> > Based on discussion in
> > https://www.postgresql.org/message-id/CAE1wr-w%
> 3DLE1cK5uG_rmAh-VBxc4_Bnw-gAE3qSqL-%3DtWwvLvjQ%40mail.gmail.com.
> >
> >
On 12/13/16 12:47 PM, Vladimir Rusinov wrote:
> Based on discussion in
> https://www.postgresql.org/message-id/CAE1wr-w%3DLE1cK5uG_rmAh-VBxc4_Bnw-gAE3qSqL-%3DtWwvLvjQ%40mail.gmail.com.
>
> Tested via regression tests.
> To be applied in master only and to be included in 10.0.
I don't think
101 - 163 of 163 matches
Mail list logo