From: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Refactor construct_array() and deconstruct_array() for built-in types |
Date: | 2022-07-01 09:41:37 |
Message-ID: | c030a2ef-02d6-ccdb-8ebe-bc97df69be59@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 02.05.22 16:48, Tom Lane wrote:
> Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> writes:
>> There are many calls to construct_array() and deconstruct_array() for
>> built-in types, for example, when dealing with system catalog columns.
>> These all hardcode the type attributes necessary to pass to these functions.
>
>> To simplify this a bit, add construct_array_builtin(),
>> deconstruct_array_builtin() as wrappers that centralize this hardcoded
>> knowledge. This simplifies many call sites and reduces the amount of
>> hardcoded stuff that is spread around.
>
>> I also considered having genbki.pl generate lookup tables for these
>> hardcoded values, similar to schemapg.h, but that ultimately seemed
>> excessive.
>
> +1 --- the added overhead of the switch statements is probably a
> reasonable price to pay for the notational simplification and
> bug-proofing.
>
> One minor coding gripe is that compilers that don't know that elog(ERROR)
> doesn't return will certainly generate "use of possibly-uninitialized
> variable" complaints. Suggest inserting "return NULL;" or similar into
> the default: cases. I'd also use more specific error wording to help
> people find where they need to add code when they make use of a new type;
> maybe like "type %u not supported by construct_array_builtin".
I have pushed this with the improvements you had suggested.
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2022-07-01 09:43:34 | Re: Perform streaming logical transactions by background workers and parallel apply |
Previous Message | Andres Freund | 2022-07-01 09:33:12 | Re: [RFC] building postgres with meson -v9 |