Re: [PATCH] psql: tab completion for ALTER ROLE ... IN DATABASE ...
| От | surya poondla |
|---|---|
| Тема | Re: [PATCH] psql: tab completion for ALTER ROLE ... IN DATABASE ... |
| Дата | |
| Msg-id | CAOVWO5p5mgJr4e+O3ugmELVMz5cYK-mxprb_9cD1emVbDVVn1g@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [PATCH] psql: tab completion for ALTER ROLE ... IN DATABASE ... ("zengman" <zengman@halodbtech.com>) |
| Список | pgsql-hackers |
Thank you Dharin, Man Zeng for the great comments.
I feel Vasuki's latest patch is in good shape.
I feel Vasuki's latest patch is in good shape.
On Tue, Jan 6, 2026 at 5:55 AM zengman <zengman@halodbtech.com> wrote:
> The only thing I’m cautious about is treating “pset.db is NULL/invalid” as just another “quoting failure” case. In this completion branch we call PQescapeLiteral(pset.db, ...) before we ever reach exec_query(), so an explicit guard is about avoiding passing an unusable handle into libpq in the first place. Even if libpq were to return NULL in that situation, it’s > not something I’d want to rely on implicitly.
> That’s why I suggested the explicit guard: it matches the general psql style of checking !pset.db before calling libpq APIs (e.g. psql_get_variable() in src/bin/psql/common.c checks !pset.db before calling PQescapeLiteral()), and it makes the intent obviously safe. Behavior-wise it’s the same (fall back to ALL), just more defensive/clear & explicit.
Hi,
Okay, I understand what you mean, thank you.
--
Regards,
Man Zeng
www.openhalo.org
В списке pgsql-hackers по дате отправления: