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

From Daniel Gustafsson
Subject Re: Remove deprecated -H option from oid2name
Date
Msg-id 30062ACD-528B-4E0E-8627-64C5136231BC@yesql.se
Whole thread Raw
In response to Re: Remove deprecated -H option from oid2name  (Peter Eisentraut <peter@eisentraut.org>)
List pgsql-hackers
> On 15 Oct 2024, at 22:48, Peter Eisentraut <peter@eisentraut.org> wrote:
>
> On 09.10.24 20:30, Daniel Gustafsson 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.
>
> The dictionary definition of "deprecate" is "to express disapproval of", which I think is about the same as your
"discouraged". If we need another term, then we should say something like "planned/scheduled to be removed". 

I guess my interpretation of "deprecated" is more in line with the Wikipedia
paragraph on deprecation in software.

    "Deprecated status may also indicate the feature will be removed in the
    future.  Features are deprecated, rather than immediately removed, to
    provide backward compatibility and to give programmers time to bring
    affected code into compliance with the new standard."

Either way, it's not a hill to die on, if the consensus is to keep features
marked deprecated then I'll withdraw this one.  It's not an important thing,
just something stumbled upon when looking at another thing.

--
Daniel Gustafsson




pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Enable data checksums by default
Next
From: Anthonin Bonnefoy
Date:
Subject: Re: Set query_id for query contained in utility statement