Re: [PATCH] Little refactoring of portalcmds.c

From: Aleksander Alekseev <aleksander(at)tigerdata(dot)com>
To: pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Cc: Zizhuan Liu <44973863(at)qq(dot)com>, quanzongliang <quanzongliang(at)yeah(dot)net>, qiuwenhuifx <qiuwenhuifx(at)gmail(dot)com>
Subject: Re: [PATCH] Little refactoring of portalcmds.c
Date: 2026-05-26 09:16:50
Message-ID: CAJ7c6TM1sktewDAcHTt19bNEN8w0+q02Okjc1t8eXcKVT9yE9w@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

> I have reviewed patch 6113 on CommitFest.
> CommitFest page: https://commitfest.postgresql.org/patch/6113/
>
> The newly introduced check_cursor_name() implements the logic to reject empty cursor names, which matches the existing checks in PerformCursorOpen() and PerformPortalFetch().
>
> However, this helper function is not a good fit for PerformPortalClose(). At the start of this function, there is a check for name == NULL — a NULL name corresponds to the CLOSE ALL command — and this check runs prior to validating whether the name is an empty string.
>
> While calling check_cursor_name() inside PerformPortalClose() would keep the current behavior intact, it could confuse future readers. This approach also fails to achieve truly consistent cursor name validation across all three functions, and may add extra maintenance burdens in the long term.
>
> On the other hand, if we only refactor PerformCursorOpen() and PerformPortalFetch(), the change would end up being rather minimal.
>
> Considering all these factors, I'd suggest leaving the code as it is.
>
> (Sorry, I tried but still cannot post this to the original thread.)

No problem, in fact from what I can tell you did everything right.

OK, let's withdraw the patch. Thanks for reviewing!

--
Best regards,
Aleksander Alekseev

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Aleksander Alekseev 2026-05-26 09:35:41 Re: [PATCH] REPLICA IDENTITY USING INDEX accepts column with invalid NOT NULL
Previous Message Richard Guo 2026-05-26 08:48:24 Fix HAVING-to-WHERE pushdown with mismatched operator families