Thread: regproc fix

regproc fix

From
Bruce Momjian
Date:
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


Re: [HACKERS] regproc fix

From
"Thomas G. Lockhart"
Date:
> 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

Re: [HACKERS] regproc fix

From
Bruce Momjian
Date:
> > 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


Re: [HACKERS] regproc fix

From
Bruce Momjian
Date:
> > 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


Re: [HACKERS] regproc fix

From
"Thomas G. Lockhart"
Date:
> > > 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

Re: [HACKERS] regproc fix

From
Bruce Momjian
Date:
> > > > 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


Re: [HACKERS] regproc fix

From
"Thomas G. Lockhart"
Date:
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