Re: unnesting multirange data types

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alexander Korotkov <aekorotkov@gmail.com>
Cc: "Jonathan S. Katz" <jkatz@postgresql.org>, Justin Pryzby <pryzby@telsasoft.com>, Zhihong Yu <zyu@yugabyte.com>, Alvaro Herrera <alvherre@alvh.no-ip.org>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-06-15T17:18:06Z
Lists: pgsql-hackers
Alexander Korotkov <aekorotkov@gmail.com> writes:
> I did run "check-world", but it passed for me.  Probably the same
> reason it passed for some buildfarm animals...

The only buildfarm animals that have passed since this went in
are the ones that don't run the pg_dump or pg_upgrade tests.

It looks to me like the proximate problem is that you should
have taught pg_dump to skip these new auto-generated functions.
However, I fail to see why we need auto-generated functions
for this at all.  Couldn't we have done it with one polymorphic
function?

I think this ought to be reverted and reviewed more carefully.

			regards, tom lane



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