On Sat, Oct 25, 2014 at 7:01 AM, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > I do think that dsm_keep_mapping is a strange name for what it does.
OK, so let me see if I can summarize the votes so far on this (highly important?) naming issue: - Andres doesn't like "unkeep". He suggests dsm_manage_mapping(), dsm_ensure_mapping_cleanup(), and dsm_remember_mapping() as possible alternatives. - Amit also doesn't like "unkeep". He suggests dsm_change_mapping(). Alternatively, he suggests having a function called dsm_manage_mapping() with an additional boolean parameter to indicate whether we are keeping or unkeeping. - Jim, without taking a position on whether the current name is problematic, suggested the naming, suggested dsm_(un)register_keep_mapping. - I am unbothered by the name "unkeep". But I suggested renaming "dsm_keep_mapping" to "dsm_unregister_mapping" and adding "dsm_register_mapping" as an alternative. - Petr liked that proposal better than the others, although it wasn't clear that he was unhappy with my original proposal. - Alvaro proposes dsm_pin_mapping/dsm_unpin_mappng. - Nobody's comments on any proposal made subsequent to the proposal they made themselves. After reviewing all of those possibilities with the sort of laser-like focus the situation demands, I'm inclined to endorse Alvaro's proposal to rename the existing dsm_keep_mapping() function to dsm_pin_mapping() and the existing dsm_keep_segment() function to dsm_pin_segment(). Then, I will add the new function as dsm_unpin_mapping(). So: 1. Does anyone strongly object to that course of action? 2. Does anyone wish to argue for or against back-patching the name changes to 9.4? My feeling is that we may as well, because either nobody's using this yet, in which case back-patching it won't break anything, or somebody is, in which case we'll cause less pain by breaking it before release than a year on. But I don't care that much either way, so I'll defer if others disagree. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers