Horton

Re: unnesting multirange data types

Jonathan S. Katz <jkatz@postgresql.org>

View thread View on postgr.es
From: "Jonathan S. Katz" <jkatz@postgresql.org>
To: Tom Lane <tgl@sss.pgh.pa.us>, Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Alexander Korotkov <aekorotkov@gmail.com>, Justin Pryzby <pryzby@telsasoft.com>, Zhihong Yu <zyu@yugabyte.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-06-15T17:59:38Z
Lists: pgsql-hackers 
On 6/15/21 1:52 PM, Tom Lane wrote:
> Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
>> On 2021-Jun-15, Tom Lane wrote:
>>> I think this ought to be reverted and reviewed more carefully.
> 
>> It seems to me that removing the cast-to-range[] is a sufficient fix,
>> and that we can do with only the unnest part for pg14; the casts can be
>> added in 15 (if at all).  That would mean reverting only half the patch.
> 
> Might be a reasonable solution.  But right now I'm annoyed that the
> buildfarm is broken, and I'm also convinced that this didn't get
> adequate testing.

I had focused testing primarily on the "unnest" cases that I had
described in my original note. I did a couple of casts and had no issue;
I did not test with pg_dump / pg_upgrade, but noting to do so in the
future in cases like this.

>  I think "revert and reconsider" is the way
> forward for today.

I don't want the buildfarm broken so I'm fine if this is the best way
forward. If we can keep the "unnest" functionality I would strongly
suggest it as that was the premise of the original note to complete the
utility of multiranges for v14. The casting, while convenient, is not
needed.

Jonathan

Commits

  1. Fix small inconsistencies in catalog definition of multirange operators

  2. Revert 29854ee8d1 due to buildfarm failures

  3. Copy-edit text for the pg_terminate_backend() "timeout" parameter.

  4. Add missing pg_description strings for pg_type entries.

  5. Fix pg_description entries for jsonb_to_record() and jsonb_to_recordset().

  6. docs: clarify JSONB operator descriptions

  7. Set procost to 10 for each of the pg_foo_is_visible() functions.

  8. Make use of LATERAL in information_schema.sequences view.

  9. Add pg_trigger_depth() function

  10. Add database comments to template0 and postgres databases, and improve