From: | Florents Tselai <florents(dot)tselai(at)gmail(dot)com> |
---|---|
To: | Joel Jacobson <joel(at)compiler(dot)org> |
Cc: | jian he <jian(dot)universality(at)gmail(dot)com>, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, Tom Dunstan <pgsql(at)tomd(dot)cc>, Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Do we want a hashset type? |
Date: | 2023-08-14 15:23:04 |
Message-ID: | 01458757-82EE-4CF0-B44F-CA617A41760E@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Has anyone put this in a git repo / extension package or similar ?
I’d like to try it out outside the core pg tree.
> On 1 Jul 2023, at 12:04 PM, Joel Jacobson <joel(at)compiler(dot)org> wrote:
>
> On Fri, Jun 30, 2023, at 06:50, jian he wrote:
>> more like a C questions
>> in this context does
>> #define HASHSET_GET_VALUES(set) ((int32 *) ((set)->data +
>> CEIL_DIV((set)->capacity, 8)))
>> define first, then define struct int4hashset_t. Is this normally ok?
>
> Yes, it's fine. Macros are just text substitutions done pre-compilation.
>
>> Also does
>> #define HASHSET_GET_VALUES(set) ((int32 *) ((set)->data +
>> CEIL_DIV((set)->capacity, 8)))
>>
>> remove (int32 *) will make it generic? then when you use it, you can
>> cast whatever type you like?
>
> Maybe, but might be less error-prone more descriptive with different
> macros for each type, e.g. INT4HASHSET_GET_VALUES,
> similar to the existing PG_GETARG_INT4HASHSET
>
> Curious to hear what everybody thinks about the interface, documentation,
> semantics and implementation?
>
> Is there anything missing or something that you think should be changed/improved?
>
> /Joel
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Japin Li | 2023-08-14 15:33:05 | Regression test collate.icu.utf8 failed on REL_14_STABLE |
Previous Message | Nathan Bossart | 2023-08-14 15:07:37 | Re: pgbench - adding pl/pgsql versions of tests |