Re: Adding a pg_get_owned_sequence function?

Greetings,

* Nathan Bossart (nathandbossart(at)gmail(dot)com) wrote:
> On Fri, Sep 01, 2023 at 01:31:43PM -0400, Tom Lane wrote:
> > Nathan Bossart <nathandbossart(at)gmail(dot)com> writes:
> >> I wonder if it'd be possible to just remove pg_get_serial_sequence().
> >
> > A quick search at http://codesearch.debian.net/ finds uses of it
> > in packages like gdal, qgis, rails, ... We could maybe get rid of
> > it after a suitable deprecation period, but I think we can't just
> > summarily remove it.

I don't agree with this- we would only be removing it from the next
major release which is a year away and our other major releases will be
supported for years to come. If we do remove it, it'd be great to
mention it to those projects and ask them to update ahead of the next
release.

> Given that, I'd still vote for marking it deprecated, but I don't feel
> strongly about actually removing it anytime soon (or anytime at all,
> really).

Why would we mark it as deprecated then? If we're not going to get rid
of it, then we're supporting it and we'll fix issues with it and that
basically means it's not deprecated. If it's broken and we're not going
to fix it, then we should get rid of it.

If we're going to actually mark it deprecated then it should be, at
least, a yearly discussion about removing it. I'm generally more in
favor of either just keeping it, or just removing it, though. We've had
very little success marking things as deprecated as a way of getting
everyone to stop using it- some folks will stop using it right away and
those are the same people who would just adapt to it being gone in the
next major version quickly, and then there's folks who won't do anything
until it's actually gone (and maybe not even then). There really isn't
a serious middle-ground where deprecation is helpful given our yearly
release cycle and long major version support period.

Thanks,

Stephen