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

Reply via email to