Vladamir, all,
* Vladimir Rusinov (vrusinov@google.com) wrote:
> On Tue, Jan 3, 2017 at 11:56 AM, Michael Paquier <michael.paquier@gmail.com>
> 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 contrib
> > modules.
>
> 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
> <https://github.com/search?q=pg_last_xlog_replay_location&type=Code&utf8=%E2%9C%93>;
> a lot of them a forks and copy-pastes, but still, that's quite a lot. Let's
> keep the aliases around for couple of versions after which hopefully a lot
> of the code will be updated.
And there's 12k hits for pg_xlog.
If we do that, we'll just end up with exactly the same question about
removing them and the same amount of code breakage in a few years. I
don't see how that is really helping anyone.
> After I'm done with a patch I can take a look if there's a way to mass-fill
> issues to affected projects on github (and maybe other hosting providers)
> and ask them to migrate to new function names. This is of course will not
> fix everything, but it would be a significant chunk. I suspect a lot of
> private tools/scripts borrow snippets from github as well.
If they're maintained, then they'll be updated. I don't have any
sympathy if they aren't maintained.
If we really feel that this is the only thing between 9.6 and 10 that'll
cause problems for some serious amount of code and we don't expect to
change the function APIs anytime in the near future then perhaps we
could keep aliases, *document* them, and treat them as full functions
just like the regular ones. Doing that requires a bit of extra
documentation and a few extra entries in pg_proc. If we ever change
them then we'll need to make sure to let people know that they're both
changing, of course, in release notes and anywhere else.
Personally, I'm not excited about keeping these as documented aliases
because, frankly, I don't think it's the only thing that's going to
break for these projects between 9.6 and 10, and if they're being well
maintained then making the change isn't going to be a big deal, but I
won't object to adding them if that's what it takes to make progress
here.
Thanks!
Stephen