Hi,
> > In one of my environments, this feature didn't work as expected.
> > Digging into it, I found that it is incompatible with FETCH_COUNT
> > being set. Sorry for not recognising this during the betas.
> >
> > Attached a simple patch with tests running the cursor declaration
> > through PQexe
On 2023-Sep-14, Tobias Bussmann wrote:
> In one of my environments, this feature didn't work as expected.
> Digging into it, I found that it is incompatible with FETCH_COUNT
> being set. Sorry for not recognising this during the betas.
>
> Attached a simple patch with tests running the cursor dec
In one of my environments, this feature didn't work as expected. Digging into
it, I found that it is incompatible with FETCH_COUNT being set. Sorry for not
recognising this during the betas.
Attached a simple patch with tests running the cursor declaration through
PQexecParams instead of PGexec
On 21.11.22 23:02, Corey Huinker wrote:
I got thinking about this, and while things may be fine as-is, I would
like to hear some opinions as to whether this behavior is correct:
This is all psql syntax, nothing specific to this command. The only
leeway is choosing the appropriate enum slash_o
On Tue, Nov 15, 2022 at 8:29 AM Peter Eisentraut <
peter.eisentr...@enterprisedb.com> wrote:
> On 09.11.22 00:12, Corey Huinker wrote:
> > As for the docs, they're very clear and probably sufficient as-is, but I
> > wonder if we should we explicitly state that the bind-state and bind
> > parameter
On 09.11.22 00:12, Corey Huinker wrote:
As for the docs, they're very clear and probably sufficient as-is, but I
wonder if we should we explicitly state that the bind-state and bind
parameters do not "stay around" after the query is executed? Suggestions
in bold:
This command causes
Peter Eisentraut wrote:
> > I assume that we may sometimes want to use the
> > extended protocol on all queries of a script, like
> > pgbench does with --protocol=extended.
>
> But is there an actual use case for this in psql? In pgbench, there are
> scenarios where you want to test asp
On 09.11.22 20:10, Daniel Verite wrote:
Peter Eisentraut wrote:
Is there a use case for a global setting?
I assume that we may sometimes want to use the
extended protocol on all queries of a script, like
pgbench does with --protocol=extended.
But is there an actual use case for this
Peter Eisentraut wrote:
> Is there a use case for a global setting?
I assume that we may sometimes want to use the
extended protocol on all queries of a script, like
pgbench does with --protocol=extended.
Outside of psql, it's too complicated to parse a SQL script to
replace the end-of-qu
>
>
> Btw., this also allows doing things like
>
> SELECT $1, $2
> \bind '1' '2' \g
> \bind '3' '4' \g
>
That's one of the things I was hoping for. Very cool.
>
> This isn't a prepared statement being reused, but it relies on the fact
> that psql \g with an empty query buffer resends the previou
On 08.11.22 13:02, Daniel Verite wrote:
A pset variable to control the default seems reasonable as well.
The implication would be that if you set that pset variable there is
no way to have individual commands use simple query mode directly.
+1 except that it would be a \set variable for consiste
.
Still kind of neat.From 076df09c701c5e60172e2dc80602726d3761e55c Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Tue, 8 Nov 2022 13:33:29 +0100
Subject: [PATCH v2] psql: Add command to use extended query protocol
This adds a new psql command \bind that sets query parameters and
causes the
David G. Johnston wrote:
> I would keep the \gp meta-command to force extended mode regardless
> of whether the query itself requires it.
+1
> A pset variable to control the default seems reasonable as well.
> The implication would be that if you set that pset variable there is
> no way
út 8. 11. 2022 v 5:21 odesílatel David G. Johnston <
david.g.johns...@gmail.com> napsal:
> On Mon, Nov 7, 2022 at 9:02 PM Pavel Stehule
> wrote:
>
>>
>>
>> út 8. 11. 2022 v 3:47 odesílatel Corey Huinker
>> napsal:
>>
>>> On Mon, Nov 7, 2022 at 4:12 PM Tom Lane wrote:
>>>
Corey Huinker wri
On Mon, Nov 7, 2022 at 9:02 PM Pavel Stehule
wrote:
>
>
> út 8. 11. 2022 v 3:47 odesílatel Corey Huinker
> napsal:
>
>> On Mon, Nov 7, 2022 at 4:12 PM Tom Lane wrote:
>>
>>> Corey Huinker writes:
>>> > I thought about basically reserving the \$[0-9]+ space as bind
>>> variables,
>>> > but it i
út 8. 11. 2022 v 3:47 odesílatel Corey Huinker
napsal:
> On Mon, Nov 7, 2022 at 4:12 PM Tom Lane wrote:
>
>> Corey Huinker writes:
>> > I thought about basically reserving the \$[0-9]+ space as bind
>> variables,
>> > but it is possible, though unlikely, that users have been naming their
>> > v
On Mon, Nov 7, 2022 at 4:12 PM Tom Lane wrote:
> Corey Huinker writes:
> > 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.
>
> Don't we already reserve that syntax as Par
Corey Huinker writes:
> 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.
Don't we already reserve that syntax as Params? Not sure whether there
would be any conflicts versus P
>
>
>
> 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 e
so 5. 11. 2022 v 7:35 odesílatel Corey Huinker
napsal:
> On Fri, Nov 4, 2022 at 11:45 AM Peter Eisentraut <
> peter.eisentr...@enterprisedb.com> wrote:
>
>> On 02.11.22 01:18, Corey Huinker wrote:
>> >
>> > SELECT $1, $2 \gp 'foo' 'bar'
>> >
>> >
>> > I think this is a great idea, but I
On Fri, Nov 4, 2022 at 11:45 AM Peter Eisentraut <
peter.eisentr...@enterprisedb.com> wrote:
> On 02.11.22 01:18, Corey Huinker wrote:
> >
> > SELECT $1, $2 \gp 'foo' 'bar'
> >
> >
> > I think this is a great idea, but I foresee people wanting to send that
> > output to a file or a pipe
On 02.11.22 01:18, Corey Huinker wrote:
SELECT $1, $2 \gp 'foo' 'bar'
I think this is a great idea, but I foresee people wanting to send that
output to a file or a pipe like \g allows. If we assume everything after
the \gp is a param, don't we paint ourselves into a corner?
Any t
On Wed, 02 Nov 2022 16:04:02 +0100
"Daniel Verite" wrote:
> Jehan-Guillaume de Rorthais wrote:
>
> > As I wrote in my TCE review, would it be possible to use psql vars to set
> > some named parameters for the prepared query? This would looks like:
> >
> > \set p1 foo
> > \set p2 bar
> >
Jehan-Guillaume de Rorthais wrote:
> As I wrote in my TCE review, would it be possible to use psql vars to set
> some
> named parameters for the prepared query? This would looks like:
>
> \set p1 foo
> \set p2 bar
> SELECT :'p1', :'p2' \gp
As I understand the feature, variables would
st 2. 11. 2022 v 13:43 odesílatel Jehan-Guillaume de Rorthais <
j...@dalibo.com> napsal:
> Hi,
>
> On Fri, 28 Oct 2022 08:52:51 +0200
> Peter Eisentraut wrote:
>
> > This adds a new psql command \gp that works like \g (or semicolon) but
> > uses the extended query protocol. Parameters can also b
Hi,
On Fri, 28 Oct 2022 08:52:51 +0200
Peter Eisentraut wrote:
> This adds a new psql command \gp that works like \g (or semicolon) but
> uses the extended query protocol. Parameters can also be passed, like
>
> SELECT $1, $2 \gp 'foo' 'bar'
As I wrote in my TCE review, would it be possi
>
>
> SELECT $1, $2 \gp 'foo' 'bar'
>
>
I think this is a great idea, but I foresee people wanting to send that
output to a file or a pipe like \g allows. If we assume everything after
the \gp is a param, don't we paint ourselves into a corner?
On Tue, 1 Nov 2022 at 20:48, Peter Eisentraut
wrote:
>
> On 01.11.22 10:10, Simon Riggs wrote:
> > On Fri, 28 Oct 2022 at 07:53, Peter Eisentraut
> > wrote:
> >>
> >> This adds a new psql command \gp that works like \g (or semicolon) but
> >> uses the extended query protocol. Parameters can also
On 01.11.22 10:10, Simon Riggs wrote:
On Fri, 28 Oct 2022 at 07:53, Peter Eisentraut
wrote:
This adds a new psql command \gp that works like \g (or semicolon) but
uses the extended query protocol. Parameters can also be passed, like
SELECT $1, $2 \gp 'foo' 'bar'
+1 for the concept. T
On Fri, 28 Oct 2022 at 07:53, Peter Eisentraut
wrote:
>
> This adds a new psql command \gp that works like \g (or semicolon) but
> uses the extended query protocol. Parameters can also be passed, like
>
> SELECT $1, $2 \gp 'foo' 'bar'
+1 for the concept. The patch looks simple and complete.
Michael Paquier writes:
> On Fri, Oct 28, 2022 at 08:52:51AM +0200, Peter Eisentraut wrote:
>> Two, for testing the extended query protocol from psql. For example, for
>> the dynamic result sets patch [1], I have several ad-hoc libpq test programs
>> lying around, which would be cumbersome to int
On Fri, Oct 28, 2022 at 08:52:51AM +0200, Peter Eisentraut wrote:
> Perhaps this would also be useful for general psql scripting.
+1
It makes great sense to that psql would support it (I've suggested to a
few people over the last few years to do that using pygres, lacking an
easier way).
I wonde
On Fri, Oct 28, 2022 at 08:52:51AM +0200, Peter Eisentraut wrote:
> Two, for testing the extended query protocol from psql. For example, for
> the dynamic result sets patch [1], I have several ad-hoc libpq test programs
> lying around, which would be cumbersome to integrate into the patch. With
>
esql.org/40/3718/
[1]: https://commitfest.postgresql.org/40/2911/From 3f4bf4a68c2edd57c7bf4c4935bad50ea0f528b7 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Fri, 28 Oct 2022 08:29:46 +0200
Subject: [PATCH] psql: Add command to use extended query protocol
This adds a new psql command \gp th
34 matches
Mail list logo
