Re: Array Iterator functions

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Rod Taylor" <rbt(at)zort(dot)ca>
Cc: "Hackers List" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Array Iterator functions
Date: 2002-04-15 19:17:27
Message-ID: 25666.1018898247@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Rod Taylor" <rbt(at)zort(dot)ca> writes:
> What would it take to make the array iterator functions a part of the
> standard base? (contrib/array)

To me, the main problem with contrib/array is that it doesn't scale:
you need more C functions for every array datatype you want to support.

At the very least it needs a way to avoid more per-datatype C code.
The per-datatype operator definitions are annoying too, but perhaps
not quite as annoying... one could imagine CREATE TYPE automatically
adding those along with the array type itself.

I'm not sure what it would take to avoid the per-datatype C code.
Clearly we want something like array_in/array_out, but how does the
extra information get to these functions?

It would also be good to have some idea of whether we could ever hope to
index queries using these functions. The GIST stuff might provide that,
or it might not. I don't insist that this work on day one, but I'd like
to see a road map, just to be sure that we are not shooting ourselves in
the foot by standardizing a not-quite-index-compatible definition.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2002-04-15 19:24:20 Re: Inefficient handling of LO-restore + Patch
Previous Message Bruce Momjian 2002-04-15 19:17:10 Re: Inefficient handling of LO-restore + Patch