From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: Refactor construct_array() and deconstruct_array() for built-in
 types
In-reply-to: <2914356f-9e5f-8c59-2995-5997fc48bcba@enterprisedb.com>
References: <2914356f-9e5f-8c59-2995-5997fc48bcba@enterprisedb.com>
Comments: In-reply-to Peter Eisentraut <peter.eisentraut@enterprisedb.com>
	message dated "Mon, 02 May 2022 10:38:59 +0200"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1844516.1651502932.1@sss.pgh.pa.us>
Date: Mon, 02 May 2022 10:48:52 -0400
Message-ID: <1844517.1651502932@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1844517.1651502932%40sss.pgh.pa.us>
Precedence: bulk

Peter Eisentraut <peter.eisentraut@enterprisedb.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".

			regards, tom lane