I wrote:
> I've been toying with the idea of converting the oidvector and
> int2vector datatypes from fixed-width arrays to variable-length;
> that is, stick a varlena length word on the front and store only
> pronargs or indnatts entries instead of a fixed number.
I have a prototype patch that does this; it gets through the regression
tests but needs cleanup, and I think contrib is still broken, so I won't
post it yet.
What I ended up doing is sticking a full ArrayType header onto these
types, so that for example the representation of oidvector is the same
as oid[] except it doesn't support toasting. This was forced by the
fact that we need to support subscripting, and the array subscripting
code expects anything that's not a fixed-length type to be a normal
array. I think this is not entirely a bad thing though, because it
means that all the array functionality Joe has been adding over the
past couple of releases now works with pg_proc.proargtypes:
regression=# select oid::regprocedure from pg_proc
regression-# where 'point'::regtype = any (proargtypes); oid
-----------------------------------point_send(point)circle_contain_pt(circle,point)pt_contained_circle(point,circle)line(point,point)point_add(point,point)point_sub(point,point)point_mul(point,point)point_div(point,point)circle(point,double
precision)...
The space savings is still pretty good, so I'm not unhappy about the
few extra bytes needed. The main thing that is bothering me at the
moment is that oidvector and int2vector are now a little TOO much like
real array types: they're tending to capture operations they shouldn't.
A couple of hacks that I've had to put in:
* dissuade format_type() from displaying oidvector as "oid[]";
* prevent find_coercion_pathway() from deciding that int[] can be implicitly casted to oidvector, as this causes at
leastone regression test failure.
I suspect there may be a few more places like this that will need
ugly hacks to prevent them from treating oidvector and int2vector
as real array types. Still, it seems like a net step forward,
especially considering the prospect that we can raise FUNC_MAX_ARGS.
Comments?
regards, tom lane
