Thread: Determining return type of polymorphic function
[Please CC any replies so I don't have to follow them via the archives] Hi, I'm trying to create a set of types that are going to share the INPUT and OUTPUT functions (written in C). For output you can determine the type from the arguments, but for INPUT you can't. The prototype is restricted (by CREATE TYPE) and you can't specify "anyelement" as the return type because none of the arguments use it. My current way around that is to create an alias to the function with different names for each type, but get_fn_expr_rettype() doesn't appear to be filled in anyway (fcinfo->flinfo->fn_expr == NULL). What I'm trying to do now is use fcinfo->flinfo->fn_oid to lookup pg_proc and get the return type from there, but something tells me there must be an easier way. Or to put it another way, if I define a function like: CREATE FUNCTION myfunction(cstring, oid, integer) RETURNS mytype AS 'mylib.so' LANGUAGE 'C'; How can I determine I'm supposed to return a "mytype"? I'm running 7.4 if it matters... Thanks in advance, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a > tool for doing 5% of the work and then sitting around waiting for someone > else to do the other 95% so you can sue them.
Martijn van Oosterhout <kleptog@svana.org> writes: > What I'm trying to do now is use fcinfo->flinfo->fn_oid to lookup > pg_proc and get the return type from there, but something tells me > there must be an easier way. No, I think you're stuck. The internal calls for type I/O routines don't set up fn_expr (since there is no expression tree). One possibility, depending on your time horizon for this, is to change the getTypeIOParam rules so that ordinary types get their own OID as second argument. regards, tom lane
Martijn van Oosterhout <kleptog@svana.org> writes: > I was thinking of actually also storing the oid in the typelem field > but the docs imply this does something fancy with subscripting. Yeah, like enable it ;-). You can't do that unless you are some kind of array type. typelem pointing at yourself would be particularly bad news --- probably lead to infinite loops ... > Would a patch to change the rules be accepted, or would it be > considered a unnecessary backward incompatable change? I wouldn't back-patch it, but it seems like something we could still put in for 8.1. regards, tom lane
[Please CC replies, thanks] On Thu, Aug 11, 2005 at 02:17:30PM -0400, Tom Lane wrote: > Martijn van Oosterhout <kleptog@svana.org> writes: > > What I'm trying to do now is use fcinfo->flinfo->fn_oid to lookup > > pg_proc and get the return type from there, but something tells me > > there must be an easier way. > > No, I think you're stuck. The internal calls for type I/O routines > don't set up fn_expr (since there is no expression tree). > > One possibility, depending on your time horizon for this, is to change > the getTypeIOParam rules so that ordinary types get their own OID as > second argument. Hmm, I was thinking about that. While reading the documentation I was thinking "surely they'd pass their own oid, giving zero would be silly" so I was kind of surprised when I did get zero. I was thinking of actually also storing the oid in the typelem field but the docs imply this does something fancy with subscripting. I havn't traced the code paths for that yet. At the very least I think it would confuse anything looking for arrays. I also thought about typmod (the third argument) but that seems to almost always be -1. Would a patch to change the rules be accepted, or would it be considered a unnecessary backward incompatable change? Thanks in advance, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a > tool for doing 5% of the work and then sitting around waiting for someone > else to do the other 95% so you can sue them.
On Thu, Aug 11, 2005 at 02:51:11PM -0400, Tom Lane wrote: > > Would a patch to change the rules be accepted, or would it be > > considered a unnecessary backward incompatable change? > > I wouldn't back-patch it, but it seems like something we could still put > in for 8.1. Ok, here's a patch (with documentation update). I checked the regression tests (looked over, not run) but nothing there appears to test this anyway. I looked through all the datatype input functions but none of them even use the second argument except array and record types and they're explicitly unchanged. Note: the logic could be simplified if we could assume composite types can't have a non-zero typelem. From looking at the code, I think it may be assumed in places and I'm fairly sure it's non-sensical, but is it explicitly forbidden? I thought of writing a few simple tests but no language will accept cstring arguments except C. It can be added if you think it's worth regression testing. Unless there are other comments I'll post this to pgsql-patches later... Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a > tool for doing 5% of the work and then sitting around waiting for someone > else to do the other 95% so you can sue them.
Forgot to attach it, oops. On Fri, Aug 12, 2005 at 09:56:47AM +0200, Martijn van Oosterhout wrote: > Ok, here's a patch (with documentation update). I checked the > regression tests (looked over, not run) but nothing there appears to > test this anyway. I looked through all the datatype input functions but > none of them even use the second argument except array and record types > and they're explicitly unchanged. > > Note: the logic could be simplified if we could assume composite types > can't have a non-zero typelem. From looking at the code, I think it may > be assumed in places and I'm fairly sure it's non-sensical, but is it > explicitly forbidden? > > I thought of writing a few simple tests but no language will accept > cstring arguments except C. It can be added if you think it's worth > regression testing. > > Unless there are other comments I'll post this to pgsql-patches > later... -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a > tool for doing 5% of the work and then sitting around waiting for someone > else to do the other 95% so you can sue them.
Attachment
Martijn van Oosterhout <kleptog@svana.org> writes: > On Fri, Aug 12, 2005 at 09:56:47AM +0200, Martijn van Oosterhout wrote: >> Ok, here's a patch (with documentation update). I checked the >> regression tests (looked over, not run) but nothing there appears to >> test this anyway. I looked through all the datatype input functions but >> none of them even use the second argument except array and record types >> and they're explicitly unchanged. >> >> Note: the logic could be simplified if we could assume composite types >> can't have a non-zero typelem. They don't. Applied with that simplification. regards, tom lane