Re: [PATCH] psql: tab completion for ALTER ROLE ... IN DATABASE ...

From: zengman <zengman(at)halodbtech(dot)com>
To: VASUKI M <vasukianand0119(at)gmail(dot)com>
Cc: Ian Lawrence Barwick <barwick(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, surya poondla <suryapoondla4(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Dharin Shah <dharinshah95(at)gmail(dot)com>
Subject: Re: [PATCH] psql: tab completion for ALTER ROLE ... IN DATABASE ...
Date: 2026-01-06 10:46:48
Message-ID: tencent_570729007E2B2BF4741F3737@qq.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> Added a safety guard before calling PQescapeLiteral() to ensure pset.db is non-NULL and in CONNECTION_OK state, falling back to ALL otherwise.

Hi, VASUKI M

I just looked at this patch and thought about it briefly, but I'm a little confused about the purpose of this conditional check.
If the condition is met, then returning anything at this point makes no sense, right?

```
if (!pset.db || PQstatus(pset.db) != CONNECTION_OK)
{
COMPLETE_WITH("ALL");
}
```

Furthermore, I believe this should be guaranteed by the function `exec_query`.

```
COMPLETE_WITH_QUERY_PLUS -> COMPLETE_WITH_QUERY_LIST -> complete_from_query -> exec_query
```

However, I haven't had time to debug it yet, so I might need your help to double-check it.

--
Regards,
Man Zeng
www.openhalo.org

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message VASUKI M 2026-01-06 10:54:22 Re: [PATCH] psql: tab completion for ALTER ROLE ... IN DATABASE ...
Previous Message Michael Banck 2026-01-06 10:38:47 Re: [PATCH] Expose checkpoint reason to completion log messages.