Vladamir, all, * Vladimir Rusinov (vrusi...@google.com) wrote: > On Tue, Jan 3, 2017 at 11:56 AM, Michael Paquier <michael.paqu...@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
signature.asc
Description: Digital signature
