From: | Ronan Dunklau <ronan(dot)dunklau(at)aiven(dot)io> |
---|---|
To: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Cc: | Greg Stark <stark(at)mit(dot)edu>, Jille Timmermans <jille(at)quis(dot)cx> |
Subject: | Re: Support for grabbing multiple consecutive values with nextval() |
Date: | 2022-07-08 08:14:06 |
Message-ID: | 2516352.Lt9SDvczpP@aivenronan |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello,
Reading the thread, I think the feature has value: it would basically transfer
control of the sequence cache to the client application.
However, I don't think that returning only the last value is a sensible thing
to do. The client will need to know the details of the sequence to do anything
useful about this, especially it's increment, minvalue, maxvalue and cycle
options.
As suggested upthread, returning a resultset would probably be better. If the
client application is concerned about the volume of data exchanged with the
server, and is willing to deal with handling the knowledge of the sequence
details themselves, they can always wrap it in an aggregate:
SELECT min(newvals), max(newvals) FROM nextvals(<num_nextvals>) as newvals
Regards,
--
Ronan Dunklau
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2022-07-08 08:59:12 | Re: [BUG] Logical replication failure "ERROR: could not map filenode "base/13237/442428" to relation OID" with catalog modifying txns |
Previous Message | Ian Lawrence Barwick | 2022-07-08 08:13:32 | Re: Support TRUNCATE triggers on foreign tables |