On 2014-01-07 11:08:22 -0500, Tom Lane wrote:
> 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.
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