> > > One remaining problem is that you have to supply the oid in
> > > quotes, because regproc has to get a string, not an int. Perhaps
> > > we need another regprocin that allows int4 or char*, but I don't
> > > think you can allow two input functions for a type.
> > > Perhaps we can just leave it. We also output the proname, even if
> > > they used the oid as input.
> > The int4 vs. string issue would be easily solved by having a routine
> > regproc(int4), which the new type coersion stuff would use
> > automatically.
> I started coding it, but realized that things like CREATE FUNCTION
> will still be looking for a string for the input function, so we would
> have to change those too. Does not seem worth the confusion.
Well, I've been really confused through this whole issue, so I'm used to
it :)
If everything works the way you want, but you would like to be able to
enter OID-style regproc names using integer conventions as well as using
string conventions, then defining this extra routine will let you do
that. No other changes, no changes to input/output routines, nada.
CREATE FUNCTION, if it works now, would continue to work; everything
else stays the same. The default behavior of handling regproc OID
identifiers as strings seems fine if it does what you need. This would
just give a user additional flexibility in how they specify regprocs for
input.
- Tom