Re: pg_stop_backup() v2 incorrectly marked as proretset

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Aleksander Alekseev <aleksander(at)timescale(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: pg_stop_backup() v2 incorrectly marked as proretset
Date: 2022-03-02 14:31:49
Message-ID: CA+Tgmoas049acSuXnvyZjbsGHDjE+uPnj5eNRLYd_yLxyHBVrw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Mar 2, 2022 at 5:25 AM Aleksander Alekseev
<aleksander(at)timescale(dot)com> wrote:
> ```
> Datum
> pg_stop_backup_v2(PG_FUNCTION_ARGS)
> {
> - ReturnSetInfo *rsinfo = (ReturnSetInfo *) fcinfo->resultinfo;
> +#define PG_STOP_BACKUP_V2_COLS 3
> TupleDesc tupdesc;
> - Tuplestorestate *tupstore;
> - MemoryContext per_query_ctx;
> - MemoryContext oldcontext;
> - Datum values[3];
> - bool nulls[3];
> + Datum values[PG_STOP_BACKUP_V2_COLS];
> + bool nulls[PG_STOP_BACKUP_V2_COLS];
> ```
>
> Declaring a macro inside the procedure body is a bit unconventional.
> Since it doesn't seem to be used for anything except these two array
> declarations I suggest keeping simply "3" here.

I think we do this kind of thing in various places in similar
situations, and I think it is good style. It makes it easier to catch
everything if you ever need to update the code.

--
Robert Haas
EDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2022-03-02 14:35:44 Re: pg_stop_backup() v2 incorrectly marked as proretset
Previous Message Peter Eisentraut 2022-03-02 14:29:59 Re: PG DOCS - logical replication filtering