[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.

Search Discussions

  • Tom Lane at Aug 11, 2005 at 6:17 pm

    Martijn van Oosterhout 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 at Aug 11, 2005 at 6:40 pm
    [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.
  • Tom Lane at Aug 11, 2005 at 6:51 pm

    Martijn van Oosterhout 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
  • Martijn van Oosterhout at Aug 12, 2005 at 7:56 am

    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.
  • Martijn van Oosterhout at Aug 12, 2005 at 12:53 pm
    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.
  • Tom Lane at Aug 12, 2005 at 9:50 pm

    Martijn van Oosterhout 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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedAug 11, '05 at 3:33p
activeAug 12, '05 at 9:50p
posts7
users2
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2021 Grokbase