Re: Adding a pg_get_owned_sequence function?

From: Nathan Bossart <nathandbossart(at)gmail(dot)com>
To: Dagfinn Ilmari Mannsåker <ilmari(at)ilmari(dot)org>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter(at)eisentraut(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Adding a pg_get_owned_sequence function?
Date: 2023-10-24 16:29:29
Message-ID: 20231024162929.GA871220@nathanxps13
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Tue, Sep 12, 2023 at 03:53:28PM +0100, Dagfinn Ilmari Mannsåker wrote:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>> It's possible that we could get away with just summarily changing
>> the argument type from text to regclass. ISTR that we did exactly
>> that with nextval() years ago, and didn't get too much push-back.
>> But we couldn't do the same for the return type. Also, this
>> approach does nothing for the concern about the name being
>> misleading.
> Maybe we should go all the way the other way, and call it
> pg_get_identity_sequence() and claim that "serial" is a legacy form of
> identity columns?

Hm. Could we split it into two functions, pg_get_owned_sequence() and
pg_get_identity_sequence()? I see that commit 3012061 [0] added support
for identity columns to pg_get_serial_sequence() because folks expected
that to work, so maybe that's a good reason to keep them together. If we
do elect to keep them combined, I'd be okay with renaming it to
pg_get_identity_sequence() along with your other proposed changes.


Nathan Bossart
Amazon Web Services:

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2023-10-24 16:47:15 Re: Add new for_each macros for iterating over a List that do not require ListCell pointer
Previous Message Robert Haas 2023-10-24 16:08:12 Re: trying again to get incremental backup