Re: int64 support in List API
От | Yura Sokolov |
---|---|
Тема | Re: int64 support in List API |
Дата | |
Msg-id | 72f3a596-ee70-47af-a064-3295c17cb8b9@postgrespro.ru обсуждение исходный текст |
Ответ на | Re: int64 support in List API (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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 по дате отправления: