Anthonin Bonnefoy wrote:
> Another possible option would be to directly send the command without
> requiring an additional meta-command, like "SELECT 1 \bind". However,
> this would make it more painful to introduce new parameters, plus it
> makes the \bind and \bind_named inconsistent as it is normally
> required to send the result with a separate meta-command.
AFAIU the reason why \bind is required (even when there are no $N
parameters in the query) is to trigger the use of the extended query
protocol. This pre-dates the pipeline feature.
But when in a pipeline, we can't send queries with the simple query
protocol anyway, so a possible usability improvement would be to make
\bind optional in that case.
Concretely it's not possible currently to issue:
\startpipeline
select 1;
it causes the error: "PQsendQuery not allowed in pipeline mode"
whereas this sequence does works:
\startpipeline
\bind
select 1;
\flushrequest
\getresults
But if the code triggered the use of the extended query protocol
if \bind is in effect *or* a pipeline is active, then the first sequence
would just push "select 1" into the pipeline.
This would have the advantage that, to submit into a pipeline
a pre-existing file with SQL commands separated with ";" you don't have
to pre-process it to inject metacommands. Adding a \startpipeline at
the beginning and an \endpipeline at the end would be sufficient in the
cases that the user does not need the results before the end.
The \sendpipeline is not mandatory when ";" can be used to terminate
the queries. But it makes it clearer that the script wants
specifically to push into a pipeline, and it might accept specific
options in the future, whereas obviously ";" cannot.
Best regards,
--
Daniel Vérité
https://postgresql.verite.pro/
