On 2014-01-07 11:08:22 -0500, Tom Lane wrote: > 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.
So, for the archives, this seems to be: * pg_cast * pg_aggregate * pg_event_trigger * pg_foreign_data_wrapper * pg_language * pg_proc (duh...) It strikes me that several of the tables using reproc could very well stand to use regprocedure instead. > 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. Yes. > And regoperator_in, too, if you wanted to auto-assign operator OIDs. I personally find that much less interesting because there are so much fewer operators in comparison to procs, so conflicts are rarer. > 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. If we're able to generate the .bki file, this seems like a solveable problem. > There are probably more issues, but those are the ones > that occur to me after thirty seconds' thought. Yes. > 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). Yes, I think that's totally out of question. > 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? I am not particularly worried about that. That'd mean somebody built a solution specifically for calling builtin functions since all user created functions will be dynamic. And that that client is using a fmgroids.h from another release than the one he's working with - a recipe for trouble in such a solution independent of this imo. > 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. That might be true. It's probably the most frequent cause for conflicts in patches people submit tho... Anyway, pg_proc's contents would need to be generated before this anyway... Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers