Re: Remove deprecated -H option from oid2name - Mailing list pgsql-hackers

From David G. Johnston
Subject Re: Remove deprecated -H option from oid2name
Date
Msg-id CAKFQuwbqhZBscOyMw1hOCWEjL0RNPOpp5z=rueVT7jDLRVurwA@mail.gmail.com
Whole thread Raw
In response to Re: Remove deprecated -H option from oid2name  (Daniel Gustafsson <daniel@yesql.se>)
Responses Re: Remove deprecated -H option from oid2name
List pgsql-hackers
On Wednesday, October 9, 2024, Daniel Gustafsson <daniel@yesql.se> wrote:
> On 9 Oct 2024, at 19:15, Nathan Bossart <nathandbossart@gmail.com> wrote:

> Another problem is that "deprecated" may or may not imply that the feature
> will be removed in the future.  IMHO we should be clear about that when we
> intend to remove something down the road (e.g., "this flag is deprecated
> and will be removed in a future major release of PostgreSQL").

That's a fair point, but if we don't aim to remove something we have, IMHO, a
social contract to maintain the feature instead and at that point it's
questionable if it is indeed deprecated.  I guess I think we should separate
between discouraged and deprecated.

I’m for the status-quo.  We don’t imply removal when we say deprecated, only that (usually) a better alternative exists.  This setup meets our existing standards.

I don’t see a need or meaningful benefit trying to add a new term “discouraged” here.  But if we do want to improve formality in this area a recap of existing discussions and its own thread would be needed.

David J.

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Using per-transaction memory contexts for storing decoded tuples
Next
From: Soumyadeep Chakraborty
Date:
Subject: Re: Syncrep and improving latency due to WAL throttling