I have implemented a regproc fix.

Now, if you supply just the pg_proc.proname, and it is unique, you can
use it.

If there is more than one match for that proname, it prints a message
saying you have to supply the oid in quotes:

	test=> create table testr(x regproc);
	CREATE
	test=> insert into testr values ('int4in');
	INSERT 18665 1
	test=> insert into testr values (300);
	ERROR:  parser: attribute 'x' is of type 'regproc' but expression is of type 'int4'
	        You will need to rewrite or cast the expression
	test=> insert into testr values ('300');
	INSERT 18666 1
	test=> insert into testr values ('int4');
	ERROR:  There is more than one procedure named oid4.
		Supply the desired pg_proc oid inside single quotes.

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.



-- 
  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


Fri, 2 Oct 1998 01:28:26 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
regproc fix
> 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.

                        - Tom

Fri, 02 Oct 1998 14:26:46 +0000
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
Re: [HACKERS] regproc fix
> > 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.

But we define a pg_type.typinput.  What do we put in there.  I assume we
can leave it alone, and allow the type coersion stuff to over-ride it.

-- 
  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


Fri, 2 Oct 1998 10:45:23 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] regproc fix
> > 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.

-- 
  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


Fri, 2 Oct 1998 11:00:19 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] regproc fix
> > > 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

Fri, 02 Oct 1998 15:23:48 +0000
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
Re: [HACKERS] regproc fix
> > > > 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


Fri, 2 Oct 1998 11:31:43 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] regproc fix
Bruce Momjian wrote:
> 
> > > > > 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.
> 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?

If you don't think so, no! ;-)

                       - Tom

Fri, 02 Oct 1998 16:23:10 +0000
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
Re: [HACKERS] regproc fix