Re: [HACKERS] NUMERIC needs OID's

Neat stuff!

> >     So  I think it's time now to move the stuff into the backend.
> >     Therefor I first need a bunch of OID's (about 30 C functions,
> >     20  SQL functions and 10 operators for now). Should I fill up
> >     all the holes?
> No, I don't recommend it.  I recommend getting a range of oid's.  Oids
> are confusing enough, without trying to collect them scattered all 
> over a range of values.
> The problem is that we don't have a range of 30 left anymore, and the
> needs of future development are surely going to eat up the rest.  One
> idea is to remove some of the conversion functions we have defined 
> that are rarely used.  We don't NEED them with Thomas's conversion 
> stuff. Thomas says native conversion is faster, but if we find some 
> that we almost never use, we could rip them out and use those.

That won't get us very many OIDs, so doesn't solve the problem in the
long run.

> However, my recommendation is that we have to start thinking about
> increasing the maximum allowable system oid.
> The max system oid is stored in transam.h as:
>         #define BootstrapObjectIdData 16384

Jan is asking for 20-50 OIDs. That is not enough to significantly affect
the size of the available "reserved OID" space. I'd recommend taking a
block of OIDs from somewhere just above the largest current pre-assigned
OID.

> I think going to 2^15 is going to become necessary someday.  The
> question is, do we do it for 6.5, and if so, how will the duplicate 
> oids affect our users?

This seems like a good subject for v7.0, when users might expect a more
troublesome transition. Anyway, by then we might have a different
solution.
                       - Tom