> > > > 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.
But no one really assigns regproc fields. They usually do it through
CREATE FUNCTION, and that would still require the quotes, so is it worth
making that exception?
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026