Re: Refactor construct_array() and deconstruct_array() for built-in types

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

In response to

Responses

Browse pgsql-hackers by date

  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