Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal - Mailing list pgsql-hackers

From Jim Nasby
Subject Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal
Date
Msg-id 9c180cf8-0a1c-a63f-eb49-478c1e4c554a@BlueTreble.com
Whole thread Raw
In response to Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal  (David Steele <david@pgmasters.net>)
Responses Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal
List 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)



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] Compiler warnings
Next
From: Jim Nasby
Date:
Subject: Re: [HACKERS] merging some features from plpgsql2 project