> > > > 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
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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
In response to
pgsql-hackers by date
|Next:||From: Thomas G. Lockhart||Date: 1998-10-02 15:40:12|
|Subject: patching utilities?|
|Previous:||From: Thomas G. Lockhart||Date: 1998-10-02 15:23:48|
|Subject: Re: [HACKERS] regproc fix|