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: <20200304022849.GA5402@alvherre.pgsql>
References: <20200304022849.GA5402@alvherre.pgsql>
Comments: In-reply-to Alvaro Herrera <alvherre@2ndquadrant.com>
	message dated "Tue, 03 Mar 2020 23:28:49 -0300"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <13799.1583612399.1@sss.pgh.pa.us>
Date: Sat, 07 Mar 2020 15:19:59 -0500
Message-ID: <13800.1583612399@sss.pgh.pa.us>
Precedence: bulk

Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> [ v11 patches ]

The cfbot isn't too happy with this; it's getting differently-ordered
results than you apparently did for the list of owned objects in
dependency.out's DROP OWNED BY test.  Not sure why that should be ---
it seems like af6550d34 should have ensured that there's only one
possible ordering.

However, what I'm on about right at the moment is that I don't think
there should be any delta in that test at all.  As far as I can see,
the design idea here is that multiranges will be automatically created
over range types, and the user doesn't need to do that.  To my mind,
that means that they're an implementation detail and should not show up as
separately-owned objects, any more than an autogenerated array type does.
So somewhere there's a missing bit of code, or more than one missing bit,
to make multiranges act as derived types, the way arrays are.

			regards, tom lane