Re: Sequence Access Methods, round two

On 8/11/2025 00:02, Michael Paquier wrote:
> On Fri, Nov 07, 2025 at 05:05:55PM +0100, Andrei Lepikhov wrote:
>> 1. For pgEdge Snowflake, it would be really beneficial - there are not only
>> code copying issues, but also the Serial -> Snowflake conversion algorithm.
>> Additionally, for now, only an in-core sequence can be used as an 'identity
>> always' column.
> 
> Perhaps pgedge is bypassing that by telling users to enforce a
> sequence rule with a function attached to an attribute default?
> Schema modifications usually feel meh for any users.
> 
Like that.

>> 2. Multimaster project [1] also attempts to resolve the sequence issue. You
>> may check how its developers tackle the problem - I guess any active-active
>> configuration needs it.
> 
> I've wanted that for 15 years or so with for strictly-monotone values
> shared across nodes, so there's that.  Remember Postgres-XC.
> 
In multimaster, you may find an implementation of strictly monotone 
sequences. This method is covered by a GUC, impolitely named as 
'Volkswagen method'. However, it adds a massive overhead and is designed 
only for very narrow cases.

I skimmed your patches. It seems that 0003 and 0007 should be the first 
patches in the set.
Additionally, the approach itself appears overly complicated to me. 
Generally, I need a kinda of type parameter (like typmod) where I can 
propose the OID of the nextval routine and extra parameters - it may be 
serialised somewhere in pg_attribute.
It seems even more flexible than a default_sequence_access_method, 
doesn't it?

-- 
regards, Andrei Lepikhov,
pgEdge