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