* Michael Paquier (michael.paquier@gmail.com) wrote:
> On Fri, Dec 30, 2016 at 8:08 PM, Vladimir Rusinov <vrusinov@google.com> 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 raises additional questions:
> > - do we keep them documented (probably not?)
> > - do we keep them forever or kill in some future version?
>
> The idea here is to keep documented only the new function names, but
> mention in the release notes that aliases are kept, and that those
> will be dropped in a couple of years (see for example 5d58c07a for
> initdb). This will give plenty of time to monitoring script
> maintainers to adapt to the new world order.
I don't particularly like this. Undocumented aliases that make things
keep working are bound to just confuse people who are looking at what's
happening (eg: logging queries) and wondering "what the heck is that
function?!" and then if they're unable to find it in the docs then they
might think it's some local function that they can remove or similar.
Worse, those function aliases will probably continue to persist for
forever because no one can agree on removing them.
We maintain back-branches for years to provide people time to adjust
their code and whatever else they need to, no one is going to be forced
to move to 10 for quite a few years yet.
Additionally, people who are actually using these bits of the system are
almost certainly going to have to adjust things for the directory
change, having to change other bits of related code nearby at the same
time is much better than someone changing just the directory now and
then having to remmeber/realize that they have to change the function
calls in a few years or "whenever the PG people decide to remove the
function aliases."
Let's make this a clean break/change. Perhaps it will also encourage
people who have their own hacked together scripts to consider using a
well maintained alternative solution.
Thanks!
Stephen