Re: Improving information_schema._pg_expandarray()

From: Dagfinn Ilmari Mannsåker <ilmari(at)ilmari(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Improving information_schema._pg_expandarray()
Date: 2024-05-13 16:56:07
Message-ID: 875xvhhcrc.fsf@wibble.ilmari.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

[ I got distracted while writing this follow-up and only just found it
in my list of unsent Gnus buffers, and now it's probably too late to
make it for 17, but here it is anyway while I remember. ]

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> I happened to notice that information_schema._pg_expandarray(),
> which has the nigh-unreadable definition
>
> AS 'select $1[s],
> s operator(pg_catalog.-) pg_catalog.array_lower($1,1) operator(pg_catalog.+) 1
> from pg_catalog.generate_series(pg_catalog.array_lower($1,1),
> pg_catalog.array_upper($1,1),
> 1) as g(s)';
>
> can now be implemented using unnest():
>
> AS 'SELECT * FROM pg_catalog.unnest($1) WITH ORDINALITY';
>
> It seems to be slightly more efficient this way, but the main point
> is to make it more readable.

I didn't spot this until it got committed, but it got me wondering what
eliminating the wrapper function completely would look like, so I
whipped up the attached. It instead calls UNNEST() laterally in the
queries, which has the side benefit of getting rid of several
subselects, one of which was particularly confusing. In one place the
lateral form eliminated the need for WITH ORDINALITY as well.

- ilmari

Attachment Content-Type Size
0001-Eliminate-information_schema._pg_expandarray-complet.patch text/x-diff 12.7 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2024-05-13 17:14:35 Re: Allowing additional commas between columns, and at the end of the SELECT clause
Previous Message Alvaro Herrera 2024-05-13 16:45:40 Re: cataloguing NOT NULL constraints