| From: | zengman <zengman(at)halodbtech(dot)com> |
|---|---|
| To: | Dharin Shah <dharinshah95(at)gmail(dot)com> |
| Cc: | VASUKI M <vasukianand0119(at)gmail(dot)com>, 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> |
| Subject: | Re: [PATCH] psql: tab completion for ALTER ROLE ... IN DATABASE ... |
| Date: | 2026-01-06 13:55:40 |
| Message-ID: | tencent_0C77CC5645E519121D45D90B@qq.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Henson Choi | 2026-01-06 13:59:18 | Re: Re[2]: [PATCH] Add pg_current_vxact_id() function to expose virtual transaction IDs |
| Previous Message | Dharin Shah | 2026-01-06 13:46:34 | Re: [PATCH] psql: tab completion for ALTER ROLE ... IN DATABASE ... |