Re: Manipulating complex types as non-contiguous structures in-memory

On 03/28/2015 11:24 PM, Tom Lane wrote:
> + /*
> + * Macros for iterating through elements of a flat or expanded array.
> + * Use "ARRAY_ITER ARRAY_ITER_VARS(name);" to declare the local variables
> + * needed for an iterator (more than one set can be used in the same function,
> + * if they have different names).
> + * Use "ARRAY_ITER_SETUP(name, arrayptr);" to prepare to iterate, and
> + * "ARRAY_ITER_NEXT(name, index, datumvar, isnullvar, ...);" to fetch the
> + * next element into datumvar/isnullvar. "index" must be the zero-origin
> + * element number; we make caller provide this since caller is generally
> + * counting the elements anyway.
> + */
> + #define ARRAY_ITER /* dummy type name to keep pgindent happy */
> +
> + #define ARRAY_ITER_VARS(iter) \
> + Datum *iter##datumptr; \
> + bool *iter##isnullptr; \
> + char *iter##dataptr; \
> + bits8 *iter##bitmapptr; \
> + int iter##bitmask

How about a struct instead?

struct ArrayIter {
Datum datumptr;
bool isnullptr;
char dataptr;
bits8 bitmapptr;
int bitmask
}

Seems more natural.

> + #define ARRAY_ITER_SETUP(iter, arrayptr) \
> [long and complicated macro]
> +
> + #define ARRAY_ITER_NEXT(iter,i, datumvar,isnullvar, elmlen,elmbyval,elmalign) \
> [another long and complicated macro]

How about turning these into functions? We have a bunch of macros like
this, but IMHO functions are much more readable and easier to debug, so
would prefer functions in new code.

In general, refactoring the array iteration code to a macro/function
like this is a good idea. It would make sense to commit that separately,
regardless of the rest of the patch.

- Heikki