Re: get rid of Pointer type, mostly

On Mon, Nov 24, 2025 at 2:38 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Well, either Peter just ran out of energy or there is actually some
> notational value in Pointer. If it's the latter, I'd like to know.

I agree that would be nice to know.

Peter's original email seemed to indicate that he was deterred by this
sort of thing:

Pointer **extra_data = (Pointer **) PG_GETARG_POINTER(4);

If Pointer is merely char *, then this is equivalent to:

char ***extra_data = (char ***) PG_GETARG_POINTER(4);

I believe this is the same extra_data that is documented thus:

extra_data is an output argument that allows extractQuery to pass
additional data to the consistent and comparePartial methods. To use
it, extractQuery must allocate an array of *nkeys pointers and store
its address at *extra_data, then store whatever it wants to into the
individual pointers. The variable is initialized to NULL before call,
so this argument can simply be ignored by operator classes that do not
require extra data. If *extra_data is set, the whole array is passed
to the consistent method, and the appropriate element to the
comparePartial method.

So in other words, it's a pointer to an array of generic pointers. In
a vacuum, I'd suggest that having three levels of indirection that are
all semantically different but all denoted by an asterisk in C is
confusing enough to be a bad idea regardless of the specifics. But
since we've already crossed that bridge, we'll just need to make the
best of it. Maybe we could use a more specific typedef here, like
GinExtraPointer. That would be a lot more greppable than just writing
Pointer, and every GinExtraPointer would be the same flavor of generic
pointer, whereas any given Pointer is not necessarily related in any
semantic way to any other.

--
Robert Haas
EDB: http://www.enterprisedb.com