Re: [PATCH] Rename pg_switch_xlog to pg_switch_wal

From: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>
To: David Steele <david(at)pgmasters(dot)net>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: Vladimir Rusinov <vrusinov(at)google(dot)com>, Cynthia Shang <cynthia(dot)shang(at)crunchydata(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Rename pg_switch_xlog to pg_switch_wal
Date: 2017-01-02 19:09:21
Message-ID: 9c180cf8-0a1c-a63f-eb49-478c1e4c554a@BlueTreble.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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 directory
>>>> change,
>>>
>>> Some *xlog* functions are commonly used to measure replay lag. That
>>> usage would not be affected by the directory renaming. Renaming those
>>> functions would only serve to annoy users and have them delay their
>>> upgrades.
>>
>> Perhaps we should split the difference and do what we did for XML:
>> provide a contrib module with alias functions using the old (xlog) names.
>
> -1
>
> Since these functions are normally used by admins and not generally used
> in SQL and functions, I'm not convinced the maintenance of the extension
> would be worth it. Admins are free to create whatever aliases they need
> to get their work done.

AIUI several others are arguing that this name change is going to break
a lot of user monitoring code. I certainly agree with Stephen that some
of the *xlog* functions are used for monitoring replay lag. So I think a
backwards compatibility fix is reasonable.

Why would we force users to each come up with their own solution to this
when we can just provide one?

BTW, I think fears of the maintenance cost of a contrib module are
pretty overblown... it's not like we change these functions that often.
We have added quite a few in the last few releases, but we don't need
backwards compatibility for new stuff.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim Nasby 2017-01-02 19:16:18 Re: merging some features from plpgsql2 project
Previous Message Tom Lane 2017-01-02 19:09:05 Re: Compiler warnings