From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
---|---|
To: | Ranier Vilela <ranier(dot)vf(at)gmail(dot)com> |
Cc: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, Richard Guo <guofenglinux(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, David Rowley <dgrowleyml(at)gmail(dot)com> |
Subject: | Re: Improve list manipulation in several places |
Date: | 2023-05-09 08:01:38 |
Message-ID: | 20230509080138.vz5udbsvsok7vjwl@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2023-May-08, Ranier Vilela wrote:
> Em seg., 8 de mai. de 2023 às 14:26, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
> escreveu:
>
> > The problem I see is that each of these new functions has a single
> > caller, and the only one that looks like it could have a performance
> > advantage is list_copy_move_nth_to_head() (which is the weirdest of the
> > lot). I'm inclined not to have any of these single-use functions unless
> > a performance case can be made for them.
> >
> I think you missed list_nth_xid, It makes perfect sense to exist.
I saw that one; it's just syntactic sugar, just like list_nth_int and
list_nth_oid, except it has only one possible callsite instead of a
dozen like those others. I see no harm in that function, but no
practical advantage to it either. Xid lists are a very fringe feature,
there being exactly one place in the whole server that uses them.
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Masahiko Sawada | 2023-05-09 08:14:35 | Re: [DOC] Update ALTER SUBSCRIPTION documentation |
Previous Message | Drouvot, Bertrand | 2023-05-09 07:14:09 | Re: Add two missing tests in 035_standby_logical_decoding.pl |