Re: [PATCH] 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(at)svana(dot)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(at)svana(dot)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

[Please CC replies, thanks]

On Thu, Aug 11, 2005 at 02:17:30PM -0400, Tom Lane wrote:
> Martijn van Oosterhout <kleptog(at)svana(dot)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(at)svana(dot)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(at)svana(dot)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

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(at)svana(dot)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(at)svana(dot)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(at)svana(dot)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