Re: psql: Add command to use extended query protocol

From: Corey Huinker <corey(dot)huinker(at)gmail(dot)com>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: psql: Add command to use extended query protocol
Date: 2022-11-07 20:27:40
Message-ID: CADkLM=fbX7NiEzjPoX97hw4bKu-_XbbR2e-Q-+3uzx+51_yH-w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>
>
>
> what about introduction new syntax for psql variables that should be
> passed as bind variables.
>

I thought about basically reserving the \$[0-9]+ space as bind variables,
but it is possible, though unlikely, that users have been naming their
variables like that.

It's unclear from your example if that's what you meant, or if you wanted
actual named variables ($name, $timestamp_before, $x).

Actual named variables might cause problems with CREATE FUNCTION AS ...
$body$ ... $body$; as well as the need to deduplicate them.

So while it is less seamless, I do like the \bind x y z \g idea because it
requires no changes in variable interpolation, and the list can be
terminated with a slash command or ;

To your point about forcing extended query protocol even when no parameters
are, that would be SELECT 1 \bind \g

It hasn't been discussed, but the question of how to handle output
parameters seems fairly straightforward: the value of the bind variable is
the name of the psql variable to be set a la \gset.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Luzanov 2022-11-07 20:37:55 Re: Add proper planner support for ORDER BY / DISTINCT aggregates
Previous Message Maciek Sakrejda 2022-11-07 18:26:06 Re: pg_stat_bgwriter.buffers_backend is pretty meaningless (and more?)