On Wed, Nov 8, 2017 at 12:41 AM, Alvaro Herrera <alvherre@xxxxxxxxxxxxxx> wrote:
> Sachin Kotwal wrote:
>> 3. Notify or highlight these changes in release notes because this can
>> break some existing tools and user code.
>
> Notifying people when their tools no longer work with a new server is
> not the problem; they figure that out pretty quickly once they try the
> new version. The problem is that if you change any names, the
> application developers need to provide version-specific queries that
> work across all the PG versions they want to support. That leads to
> some pretty horrible code, annoyed developers, bad publicity for Pg
> ("you guys don't love your app developers!"), etc.
This reminds me of pg_stat_activity whose pid column has been renamed,
and this column is widely used for monitoring... My experience on that
is that renaming induces technical debts, but applications would see
queries failing immediately, which is not complicated to grep and fix
properly as frontend code usually has already logic to track the
backend version number, and even if any deeper modification is needed
things like libpq allow to fetch the backend version easily. Column
name of function name changes happen (see xlog -> wal switch in v10),
and community is usually driven by consensus. So if there is a
proposal adopted by a majority of hackers thinking that changing a
column is worth long-term, then it could be considered for
integration. I personally tend to take with a pinch of salt such
proposals though if there are no good reasons behind a switch other
than because it-is-beautiful, so I agree with Álvaro that it is good
to be careful here.
--
Michael
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
