Обсуждение: regproc fix
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
> 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
> > 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
> > 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
> > > 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
> > > > 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
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