| From: | Nico Williams <nico(at)cryptonector(dot)com> |
|---|---|
| To: | Frits Hoogland <frits(dot)hoogland(at)gmail(dot)com> |
| Cc: | Jeremy Schneider <schneider(at)ardentperf(dot)com>, Kirill Reshke <reshkekirill(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Dave Cramer <davecramer(at)postgres(dot)rocks> |
| Subject: | Re: protocol support for labels |
| Date: | 2025-03-11 19:03:12 |
| Message-ID: | Z9CI8B1bYF+u63pq@ubby |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Mar 11, 2025 at 05:23:14PM +0100, Frits Hoogland wrote:
> The usecase that I think might be useful is to have a database client send metadata along with a query.
> This partially is possible today by setting application_name, but that is a separate request, it would be great if that could be sent along with the query in one go.
> Another option to pass metadata is to add a comment (/* .. */), but a comment cannot be set for a prepared statement, because the statement is prepared first and then later invoked on runtime, which executes a query that is fixed.
How about using a `set_config()` to deonte the "application_name" (and
any other details) for the _next_ query, then have those details appear
in the pg_stat_statements rows and logs?
Clients would send a `SELECT set_config(...)` and also the next query
one after the other without waiting for the response to the first. The
server could similarly batch the two responses.
Look ma', no protocol change.
Nico
--
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2025-03-11 19:29:29 | Re: Some read stream improvements |
| Previous Message | Dave Cramer | 2025-03-11 18:56:43 | Re: protocol support for labels |