Thread: Re: Remove deprecated -H option from oid2name
On Wed, Oct 09, 2024 at 10:08:31AM +0200, Daniel Gustafsson wrote: > The -H option to oid2name was deprecated in v12, and with v12 going out of > support it seems about time to remove it for v18. Not the most groundbreaking > cleanup, but also no point in carrying it around for 5 more years. Seems fine to me, although I don't see a problem with keeping it, either. -- nathan
> On 9 Oct 2024, at 18:33, Nathan Bossart <nathandbossart@gmail.com> wrote: > > On Wed, Oct 09, 2024 at 10:08:31AM +0200, Daniel Gustafsson wrote: >> The -H option to oid2name was deprecated in v12, and with v12 going out of >> support it seems about time to remove it for v18. Not the most groundbreaking >> cleanup, but also no point in carrying it around for 5 more years. > > Seems fine to me, although I don't see a problem with keeping it, either. There is little to no cost in keeping it, but then we might as well remove the deprecation notice. If we keep marking things deprecated without removing them then we risk being seen as crying wolf and users stop caring to update away from things we really want to deprecate. -- Daniel Gustafsson
On Wed, Oct 09, 2024 at 06:45:07PM +0200, Daniel Gustafsson wrote: >> On 9 Oct 2024, at 18:33, Nathan Bossart <nathandbossart@gmail.com> wrote: >> >> On Wed, Oct 09, 2024 at 10:08:31AM +0200, Daniel Gustafsson wrote: >>> The -H option to oid2name was deprecated in v12, and with v12 going out of >>> support it seems about time to remove it for v18. Not the most groundbreaking >>> cleanup, but also no point in carrying it around for 5 more years. >> >> Seems fine to me, although I don't see a problem with keeping it, either. > > There is little to no cost in keeping it, but then we might as well remove the > deprecation notice. If we keep marking things deprecated without removing them > then we risk being seen as crying wolf and users stop caring to update away > from things we really want to deprecate. I tend to agree, but I still think it's worth considering whether removing a few lines of code is worth breaking folks' scripts. In this case, I'm not too worried... 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"). -- nathan
> 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. -- Daniel Gustafsson
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".
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.
On 16 Oct 2024, at 06:57, David G. Johnston <david.g.johnston@gmail.com> wrote:
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.
The status-quo is inconsistency, we sometimes remove features we've marked as
deprecated and sometimes they are kept.
--
Daniel Gustafsson
Daniel Gustafsson
> 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