Andres Freund <andres@2ndquadrant.com> writes:
> To the point that I am not seing the problem right now. I am not
> proposing to get rid of statically assigned oids in pg_type et al.. The
> references to procs mostly seem to be typed 'regproc' so there aren't
> many references to function's oids.
*Some* of them are typed regproc. Many are not, because there's need to
refer to overloaded function names.
A minimum change before we could even consider abandoning auto assignment
of pg_proc entries would be to make regprocedure_in work in bootstrap
mode, so that we could use regprocedure as a catalog column type. And
regoperator_in, too, if you wanted to auto-assign operator OIDs. And
you'd need some solution for generating fmgroids.h, as well as the
handmade #define's for selected operator OIDs that appear now in
pg_operator.h. There are probably more issues, but those are the ones
that occur to me after thirty seconds' thought.
Even after all that, we can *not* go over to auto-assignment of pg_type
OIDs, because there is way too much stuff that assumes those OIDs are
stable (starting with on-disk storage of arrays). I'm not entirely
sure that it's okay to have function OIDs varying across releases, either;
who's to say that there's not client code looking at fmgroids.h, or
otherwise hard-wiring the numbers it uses for fastpath function calls?
On the whole I think that this'd be a lot more work, and a lot more
potential for breakage, than it's really worth.
regards, tom lane