Conor McNally <theconor@gmail.com> writes:
> The line about it being faster gives me the reassurance that I need. From
> just the introduction I was unsure of the actual benefit over int[] - the
> operators look like they can all be replicated using the standard library,
> albeit in much more convoluted ways! Is it general advice therefore that
> if I've got an array of intergers, no nulls, it is advantageous for me to
> install and use intarray, and I'd really only want to use int[] if I had
> nulls? Or is there something more to it?
TBH, I think that intarray is legacy code that we haven't got around to
replacing completely, but the handwriting is on the wall. No one has put
any meaningful development effort into it in years; rather, the action
has been in improving the core code's array functionality. And there are
definitely gotchas involved in using it without care. Because it offers
variant versions of some of the same operator names defined by the core,
you can get cases where a query will not use an index because the query
is using the extension's <@ operator where the index is for the core <@
operator, or vice versa. (See list archives for many complaints of
this kind.)
If you can show that use of intarray offers life-changing improvements
for your application over what the core code can do for you, then by
all means use it. If it doesn't offer strong, measurable improvements,
I counsel against getting involved with it.
regards, tom lane