Re: Determining return type of polymorphic function - Mailing list pgsql-hackers

From Martijn van Oosterhout
Subject Re: Determining return type of polymorphic function
Date
Msg-id 20050812075647.GC4305@svana.org
Whole thread Raw
In response to Re: Determining return type of polymorphic function  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [PATCH] Determining return type of polymorphic function  (Martijn van Oosterhout <kleptog@svana.org>)
List pgsql-hackers
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.

pgsql-hackers by date:

Previous
From: ITAGAKI Takahiro
Date:
Subject: Re: Why do index access methods use LP_DELETE?
Next
From: Kim Bisgaard
Date:
Subject: Re: Project proposal/comments please - query optimization