From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
cc: Paul A Jungwirth <pj@illuminatedcomputing.com>,
        Pavel Stehule <pavel.stehule@gmail.com>,
        Jeff Davis <pgsql@j-davis.com>,
        Pgsql Hackers <pgsql-hackers@postgresql.org>
Subject: Re: range_agg
In-reply-to: <20191220192901.GA9955@alvherre.pgsql>
References: <20191220192901.GA9955@alvherre.pgsql>
Comments: In-reply-to Alvaro Herrera <alvherre@2ndquadrant.com>
	message dated "Fri, 20 Dec 2019 16:29:01 -0300"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <9925.1576876524.1@sss.pgh.pa.us>
Date: Fri, 20 Dec 2019 16:15:24 -0500
Message-ID: <9926.1576876524@sss.pgh.pa.us>
Precedence: bulk

Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> On 2019-Dec-20, Paul A Jungwirth wrote:
>> Is it permitted to add casts with polymorphic inputs & outputs? Is
>> that something that we would actually want to do? I'd probably need
>> both the polymorphic and concrete casts so that you could still say
>> `int4range(1,2)::int4multirange`.

> I'm embarrased to admit that I don't grok the type system well enough
> (yet) to answer this question.

I would say no; if you want behavior like that you'd have to add code for
it into the coercion machinery, much like the casts around, say, types
record and record[] versus named composites and arrays of same.  Expecting
the generic cast machinery to do the right thing would be foolhardy.

In any case, even if it did do the right thing, you'd still need
some additional polymorphic type to express the behavior you wanted,
no?  So it's not clear there'd be any net savings of effort.

			regards, tom lane