Re: pg_stop_backup() v2 incorrectly marked as proretset
От
Julien Rouhaud
Тема
Re: pg_stop_backup() v2 incorrectly marked as proretset
Дата
Msg-id
20220302163632.6ppfefpw4usen6z5@jrouhaud
Ответ на
Re: pg_stop_backup() v2 incorrectly marked as proretset (Aleksander Alekseev)
Список
Дерево обсуждения
pg_stop_backup() v2 incorrectly marked as proretset Michael Paquier <michael@paquier.xyz>
Re: pg_stop_backup() v2 incorrectly marked as proretset Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Re: pg_stop_backup() v2 incorrectly marked as proretset Michael Paquier <michael@paquier.xyz>
Re: pg_stop_backup() v2 incorrectly marked as proretset Aleksander Alekseev <aleksander@timescale.com>
Re: pg_stop_backup() v2 incorrectly marked as proretset Robert Haas <robertmhaas@gmail.com>
Re: pg_stop_backup() v2 incorrectly marked as proretset Tom Lane <tgl@sss.pgh.pa.us>
Re: pg_stop_backup() v2 incorrectly marked as proretset Robert Haas <robertmhaas@gmail.com>
Re: pg_stop_backup() v2 incorrectly marked as proretset Tom Lane <tgl@sss.pgh.pa.us>
Re: pg_stop_backup() v2 incorrectly marked as proretset Chapman Flack <chap@anastigmatix.net>
Re: pg_stop_backup() v2 incorrectly marked as proretset Tom Lane <tgl@sss.pgh.pa.us>
Re: pg_stop_backup() v2 incorrectly marked as proretset Michael Paquier <michael@paquier.xyz>
Re: pg_stop_backup() v2 incorrectly marked as proretset Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Re: pg_stop_backup() v2 incorrectly marked as proretset Aleksander Alekseev <aleksander@timescale.com>
Re: pg_stop_backup() v2 incorrectly marked as proretset Julien Rouhaud <rjuju123@gmail.com>
Re: pg_stop_backup() v2 incorrectly marked as proretset Michael Paquier <michael@paquier.xyz>
Re: pg_stop_backup() v2 incorrectly marked as proretset Chapman Flack <chap@anastigmatix.net>
Re: pg_stop_backup() v2 incorrectly marked as proretset David Steele <david@pgmasters.net>
Re: pg_stop_backup() v2 incorrectly marked as proretset Michael Paquier <michael@paquier.xyz>
On Wed, Mar 02, 2022 at 05:40:00PM +0300, Aleksander Alekseev wrote: > Hi Tom. > > Yeah, there's plenty of precedent for that coding if you look around. > > I've not read the whole patch, but this snippet seems fine to me > > if there's also an #undef at the end of the function. > > No, there is no #undef. With #undef I don't mind it either. I don't see strong evidence for that pattern being wildly used with some naive grepping: #define for such use without undef: POSTGRES_FDW_GET_CONNECTIONS_COLS HEAP_TUPLE_INFOMASK_COLS CONNECTBY_NCOLS DBLINK_NOTIFY_COLS PG_STAT_STATEMENTS_COLS PG_STAT_STATEMENTS_INFO_COLS HEAPCHECK_RELATION_COLS PG_PARTITION_TREE_COLS PG_STAT_GET_ACTIVITY_COLS PG_STAT_GET_WAL_COLS PG_STAT_GET_SLRU_COLS PG_STAT_GET_REPLICATION_SLOT_COLS PG_STAT_GET_SUBSCRIPTION_STATS_COLS PG_GET_BACKEND_MEMORY_CONTEXTS_COLS PG_GET_SHMEM_SIZES_COLS PG_GET_REPLICATION_SLOTS_COLS READ_REPLICATION_SLOT_COLS PG_STAT_GET_WAL_SENDERS_COLS PG_STAT_GET_SUBSCRIPTION_COLS With an undef: REPLICATION_ORIGIN_PROGRESS_COLS
В списке pgsql-hackers по дате отправления