Re: int64 support in List API - Mailing list pgsql-hackers

From Yura Sokolov
Subject Re: int64 support in List API
Date
Msg-id 72f3a596-ee70-47af-a064-3295c17cb8b9@postgrespro.ru
Whole thread Raw
In response to Re: int64 support in List API  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
20.01.2025 07:36, Tom Lane пишет:
> Gurjeet Singh <gurjeet@singh.im> writes:
>> I wanted to use the list api from pg_list.h. It has special implementations for
>> int, oid, pointer, and xid types, which help with lower code overhead (no need
>> to create structures whose sole member is of one of these types) and  better
>> performance. So I was wondering if there's any interest in having a similar API
>> for int64 type, as well.
> 
> This has been discussed before, and we've felt that it wasn't worth
> the additional code duplication.  I would not favor approaching this
> with the mindset of lets-copy-and-paste-all-the-code.
> 
> However: it might be interesting to think about having just two
> underlying implementations, one for 32-bit datums and one for 64-bits,
> with the existing APIs becoming macros-with-casts wrappers around the
> appropriate one of those.  That line of attack might lead to
> physically less code not more.  The devil's in the details though.

There's masterpiece typesafe std-C compliant macros+functions 
implementation of vector:

https://github.com/rxi/vec/

It wraps any struct with "T *data; int length; int capacity" fields, and 
uses `sizeof(*(v)->data)` to instruct wrapped allocation/move functions.

Although it could not be directly adapted to List*, and it is less 
sophisticated considering "mutation during iteration", it could be 
really useful in many places, where List* used not as a Node, but just 
as dynamic array.



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: int64 support in List API
Next
From: Kashif Zeeshan
Date:
Subject: Re: [PoC] Federated Authn/z with OAUTHBEARER