Andres Freund <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers