Hi Solai, Thanks for testing my patch!
On Fri, Oct 30, 2026 at 4:36 PM solai v <[email protected]> wrote: ... > > Thank you for the updated patch. I tested the tab-completion behaviour > for publication and subscription options and inspected the relevant > completion logic in src/bin/psql/tab-complete.in.c. The completion > suggestions are displayed correctly when the cursor is immediately > after the opening parenthesis. For example: ALTER PUBLICATION test_pub > SET ( > However, the suggestions are not displayed when entering subsequent > options after a comma. For example: ALTER PUBLICATION test_pub SET > (publish = 'insert', IIUC, the problem is only that there was no space after the comma. If you add a space, it works fine: ALTER PUBLICATION test_pub SET (publish = 'insert', <TAB> > I investigated the relevant completion conditions and the > complete_from_list() implementation in src/bin/psql/tab-complete.c. > The current completion logic attempts to handle this case using > text[0] == ','. However, complete_from_list() uses the current text as > a prefix when filtering the completion candidates. Since the prefix is > a comma, it does not match the available option names, and > consequently no suggestions are displayed. I'm not sure what "text[0] == ','" check you're referring to. The comma handling is only this: if (ends_with(prev_wd, '(') || ends_with(prev_wd, ',')) With the space, the word being completed is empty and prev_wd is "'insert',", so the above matches and the options are offered. The other comma-separated lists in tab-complete.in.c also expect a space after the comma. e.g. the existing "CREATE PUBLICATION ... FOR ALL TABLES EXCEPT ( ..." uses (!ends_with(prev_wd, ',')) in the same way. > I also checked the WORD_BREAKS definition and observed that the comma > is not currently included in it. Could you please look into this > behaviour and consider an appropriate way to support completion after > commas without affecting other existing psql completion contexts? > AFAIK, that is a known limitation of psql tab-completion in general; it is not specific to this patch. The WORD_BREAKS question has come up a few times before: * Actually, I proposed adding the comma to WORD_BREAKS back in 2022 [1]. Tom Lane replied [2] that the WORD_BREAKS list looked quite random, and said he would like to see it populated more fully, with the reasons for any omissions documented. * In April 2024, Tom Lane wondered again why comma isn't in there [3]. So, changing WORD_BREAKS might be worthwhile, but it would need its own thread (and ideally more tab-complete test coverage), because it affects all psql tab-completion, not just pub/sub options. Therefore, I think it is out of scope for this patch. ====== [1] https://www.postgresql.org/message-id/CAHut%2BPvUShR5SHgm2pUj_8xcH%3D8CmqBjFcOdvjx%2B1j6b%3D_K2DQ%40mail.gmail.com [2] https://www.postgresql.org/message-id/431600.1642554676%40sss.pgh.pa.us [3] https://www.postgresql.org/message-id/3870833.1712696581%40sss.pgh.pa.us Kind Regards, Peter Smith. Fujitsu Australia
