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 19026One 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 19026One 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 19026Bruce 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