From: | Dagfinn Ilmari Mannsåker <ilmari(at)ilmari(dot)org> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Refactor construct_array() and deconstruct_array() for built-in types |
Date: | 2022-07-01 10:47:50 |
Message-ID: | 87y1xdjei1.fsf@wibble.ilmari.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Dagfinn Ilmari Mannsåker <ilmari(at)ilmari(dot)org> writes:
> I dind't pay much attention to this thread earlier, but I was struck by
> the duplication of the switch statement determining the elemlen,
> elembyval, and elemalign values between the construct and deconstruct
> functions. How about a common function they can both call? Something
> like:
>
> static void builtin_type_details(Oid elemtype,
> int *elemlen,
> bool *elembyval,
> char *elemalign);
I just realised that this would require the error message to not include
the function name (which isn't really that critical, since it's a
developer-facing message), but an option would to make it return false
for unknown types, so each of the calling functions can emit their own
error message.
> - ilmari
From | Date | Subject | |
---|---|---|---|
Next Message | Ranier Vilela | 2022-07-01 11:10:37 | Re: Avoid unecessary MemSet call (src/backend/utils/cache/relcache.c) |
Previous Message | Dagfinn Ilmari Mannsåker | 2022-07-01 10:43:21 | Re: Refactor construct_array() and deconstruct_array() for built-in types |