> > > 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
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
In response to
pgsql-hackers by date
|Next:||From: Bruce Momjian||Date: 1998-10-02 15:31:43|
|Subject: Re: [HACKERS] regproc fix|
|Previous:||From: Bruce Momjian||Date: 1998-10-02 15:22:27|
|Subject: Re: [HACKERS] spinlock code for ns32k (again)|