Re: FUNC_MAX_ARGS benchmarks

Hannu Krosing <hannu@tm.ee> writes:
>> Lack of btree index support for _oid would be the first hurdle.

> Is that index really needed, or is it there just to enforce uniqueness ?

Both.

> Also, (imho ;) btree index support should be done for all array types
> which have comparison ops for elements at once (with semantics similar
> to string) not one by one for individual types.

Fine, send a patch ;-)

>> Even if we wanted to do that work, there'd be some serious breakage
>> of client queries because of the historical differences in output format
>> and subscripting.  (oidvector indexes from 0, _oid from 1.  Which is
>> pretty bogus, but if the regression tests are anything to judge by there
>> are probably a lot of queries out there that know this.)

> I would guess that oidvector is sufficiently obscure type and that
> nobody actually uses oidvector for user tables. 

No, you miss my point: client queries that do subscripting on
proargtypes will break.  Since the regression tests find this a useful
thing to do, I suspect there are clients out there that do too.

> But going to _oid will free us from arbitrary limits on argument count.

I didn't say it wouldn't be a good idea in the long run.  I'm saying I
don't think it's happening for 7.3, given that Aug 31 is not that far
away anymore and that a lot of cleanup work remains undone on other
already-committed features.  FUNC_MAX_ARGS=32 could happen for 7.3, though.
        regards, tom lane