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

=?utf-8?Q?Dagfinn_Ilmari_Manns=C3=A5ker?= <ilmari(at)ilmari(dot)org> writes:
> 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?

I was wondering about that too while reading the committed version.
However, adding an additional function call would weaken the argument
that this adds just a tolerable amount of overhead, primarily because
you'd need to return a record or introduce pointers or the like.

> 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.

Nah, because the point of that was just to direct people to where
to fix it when they need to. So the message need only refer to
the common function, if we were to change it.

Perhaps a good compromise could be to turn the duplicated code into
a macro that's instantiated in both places? But I don't actually
see anything much wrong with the code as Peter has it.

regards, tom lane