Hannu Krosing <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]