On Mon, Oct 13, 2008 at 7:01 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Merlin Moncure" <mmoncure@gmail.com> writes:
>> On Mon, Oct 13, 2008 at 9:56 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> I'm inclined to apply the patch with binary-coercibility adjustments
>>> and not try to turn RECORD or RECORD[] into full-fledged polymorphic
>>> types. It's not immediately clear what the use of that would be
>>> anyway.
>
>> ...meaning, that you would not be able to create a function taking
>> generic 'record' as a parameter?
>
> Well, you've never been able to do that, although for many of the PLs
> there doesn't seem to be any very fundamental reason why not. But
> I was actually wondering about something beyond that: should we have the
> equivalent of the polymorphic-type behaviors for composites? That would
> mean rules along the line of "all records mentioned in the call and
> result are the same composite type" and "record[] means the array type
> corresponding to whichever type record is".
>
> We don't seem to need these things in order to solve the recursion cycle
> detection problem, so I'm not very excited about pursuing the line of
> thought any further right now.
Here is another use-case solved by the patch. Previously, there was
no easy way to index on a composite function result. The following
works in HEAD:
create function func(f foo, a out int, b out int) returns record ...
create index foo_idx on foo(func(foo));
The point being, you can now directly index the return composite vs.
trying to deal with the headache of expanding the function result.
You might see this in userland if trying to index on a parsed
expression. Really nice...composites are first class citizens now...
merlin
