On 20.02.23 13:58, Peter Eisentraut wrote:
The attached patches are the same as before, rebased over master and
split up as described. I haven't done any significant work on the
contents, but I will try to get the 0001 patch into a more polished
state soon.
I've done a bit of work on this
On 31.01.23 12:07, Peter Eisentraut wrote:
Applying this patch, your test queries seem to work correctly.
Great!
This is quite WIP, especially because there's a couple of scenarios
uncovered by tests that I'd like to ensure correctness about, but if you
would like to continue adding tests
On 30.01.23 14:06, Alvaro Herrera wrote:
On 2022-Nov-22, Peter Eisentraut wrote:
I added tests using the new psql \bind command to test this functionality in
the extended query protocol, which showed that this got broken since I first
wrote this patch. This "blame" is on the pipeline mode in
On 2022-Nov-22, Peter Eisentraut wrote:
> I added tests using the new psql \bind command to test this functionality in
> the extended query protocol, which showed that this got broken since I first
> wrote this patch. This "blame" is on the pipeline mode in libpq patch
>
On 2022-Dec-21, Alvaro Herrera wrote:
> I suppose that in order for this to work, we would have to find another
> way to "advance" the queue that doesn't rely on the status being
> PGASYNC_READY.
I think the way to make this work is to increase the coupling between
fe-exec.c and fe-protocol.c by
On 2022-Nov-22, Peter Eisentraut wrote:
> I added tests using the new psql \bind command to test this functionality in
> the extended query protocol, which showed that this got broken since I first
> wrote this patch. This "blame" is on the pipeline mode in libpq patch
>
On 14.10.22 09:11, Peter Eisentraut wrote:
Now that the psql support for multiple result sets exists, I want to
revive this patch. It's the same as the last posted version, except now
it doesn't require any psql changes or any weird test modifications
anymore.
(Old news: This patch allows
On 14.10.22 19:22, Pavel Stehule wrote:
1. there can be possibility to set "dynamic result sets" to unknown. The
behaviour of the "dynamic result sets" option is a little bit confusing.
I expect the number of result sets should be exactly the same as this
number. But the warning is raised only
Hi
pá 14. 10. 2022 v 9:12 odesílatel Peter Eisentraut <
peter.eisentr...@enterprisedb.com> napsal:
> On 01.02.22 15:40, Peter Eisentraut wrote:
> > On 12.01.22 11:20, Julien Rouhaud wrote:
> >> Since you mentioned that this patch depends on the SHOW_ALL_RESULTS
> >> psql patch
> >> which is
On 01.02.22 15:40, Peter Eisentraut wrote:
On 12.01.22 11:20, Julien Rouhaud wrote:
Since you mentioned that this patch depends on the SHOW_ALL_RESULTS
psql patch
which is still being worked on, I'm not expecting much activity here
until the
prerequirements are done. It also seems better to
On 12.01.22 11:20, Julien Rouhaud wrote:
Since you mentioned that this patch depends on the SHOW_ALL_RESULTS psql patch
which is still being worked on, I'm not expecting much activity here until the
prerequirements are done. It also seems better to mark this patch as Waiting
on Author as
Hi,
On Mon, Aug 30, 2021 at 02:11:34PM -0700, Zhihong Yu wrote:
> On Mon, Aug 30, 2021 at 1:23 PM Peter Eisentraut <
> peter.eisentr...@enterprisedb.com> wrote:
>
> > rebased patch set
>
> +WITH RETURN
> +WITHOUT RETURN
> +
> +
> + This option is only valid for cursors
On Mon, Aug 30, 2021 at 1:23 PM Peter Eisentraut <
peter.eisentr...@enterprisedb.com> wrote:
> rebased patch set
>
> On 22.07.21 08:06, vignesh C wrote:
> > On Tue, Jun 29, 2021 at 7:10 PM Peter Eisentraut
> > wrote:
> >>
> >> Here is an updated patch with some merge conflicts resolved, to keep
rebased patch set
On 22.07.21 08:06, vignesh C wrote:
On Tue, Jun 29, 2021 at 7:10 PM Peter Eisentraut
wrote:
Here is an updated patch with some merge conflicts resolved, to keep it
fresh. It's still pending in the commit fest from last time.
My focus right now is to work on the "psql -
On Tue, Jun 29, 2021 at 7:10 PM Peter Eisentraut
wrote:
>
> Here is an updated patch with some merge conflicts resolved, to keep it
> fresh. It's still pending in the commit fest from last time.
>
> My focus right now is to work on the "psql - add SHOW_ALL_RESULTS
> option" patch
Here is an updated patch with some merge conflicts resolved, to keep it
fresh. It's still pending in the commit fest from last time.
My focus right now is to work on the "psql - add SHOW_ALL_RESULTS
option" patch (https://commitfest.postgresql.org/33/2096/) first, which
is pretty much a
On 15.03.21 14:56, David Steele wrote:
Hi Peter,
On 12/30/20 9:33 AM, Peter Eisentraut wrote:
On 2020-10-09 20:46, Andres Freund wrote:
Is there really a good reason for forcing the client to issue
NextResult, Describe, Execute for each of the dynamic result sets? It's
not like there's
Hi Peter,
On 12/30/20 9:33 AM, Peter Eisentraut wrote:
On 2020-10-09 20:46, Andres Freund wrote:
Is there really a good reason for forcing the client to issue
NextResult, Describe, Execute for each of the dynamic result sets? It's
not like there's really a case for allowing the clients to skip
On 2020-10-09 20:46, Andres Freund wrote:
Is there really a good reason for forcing the client to issue
NextResult, Describe, Execute for each of the dynamic result sets? It's
not like there's really a case for allowing the clients to skip them,
right? Why aren't we sending something more like
On 2020-10-20 12:24, Dave Cramer wrote:
Finally, we could do it an a best-effort basis. We use binary format
for registered types, until there is some invalidation event for the
type, at which point we revert to default/text format until the end
of a
session (or until
Hi,
On 2020-10-20 20:17:45 -0400, Dave Cramer wrote:
> You are correct we are not talking about a whole new protocol, but why not ?
> Seems to me we would have a lot more latitude to get it right if we didn't
> have this limitation.
A new protocol will face a much bigger adoption hurdle, and
On Tue, 20 Oct 2020 at 20:09, Andres Freund wrote:
> Hi,
>
> On 2020-10-20 18:55:41 -0500, Jack Christensen wrote:
> > Upthread someone posted a page pgjdbc detailing desired changes to the
> > backend protocol (
> >
>
Hi,
On 2020-10-20 18:55:41 -0500, Jack Christensen wrote:
> Upthread someone posted a page pgjdbc detailing desired changes to the
> backend protocol (
> https://github.com/pgjdbc/pgjdbc/blob/master/backend_protocol_v4_wanted_features.md).
A lot of the stuff on there seems way beyond what can be
Regarding decoding binary vs text performance: There can be a significant
performance cost to fetching the binary format over the text format for
types such as text. See
https://www.postgresql.org/message-id/CAMovtNoHFod2jMAKQjjxv209PCTJx5Kc66anwWvX0mEiaXwgmA%40mail.gmail.com
for the previous
Very interesting conversation, thanks for including me Dave. Here are some
thoughts from the Npgsql perspective,
Re the binary vs. text discussion... A long time ago, Npgsql became a
"binary-only" driver, meaning that it never sends or receives values in
text encoding, and practically always uses
On Tue, 20 Oct 2020 at 05:57, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 2020-10-09 21:02, Dave Cramer wrote:
> > For the most part we know exactly which types we want in binary for 99%
> > of queries.
> >
> > The hard part around this really is whether and how to deal
On 2020-10-09 21:02, Dave Cramer wrote:
For the most part we know exactly which types we want in binary for 99%
of queries.
The hard part around this really is whether and how to deal with changes
in type definitions. From types just being created - comparatively
simple - to
On Fri, 9 Oct 2020 at 14:59, Andres Freund wrote:
> Hi,
>
> On 2020-10-09 14:49:11 -0400, Dave Cramer wrote:
> > On Fri, 9 Oct 2020 at 14:46, Andres Freund wrote:
> > > > (I suspect what would be more useful in practice is to designate
> > > > output formats per data type.)
> > >
> > > Yea,
Hi,
On 2020-10-09 14:49:11 -0400, Dave Cramer wrote:
> On Fri, 9 Oct 2020 at 14:46, Andres Freund wrote:
> > > (I suspect what would be more useful in practice is to designate
> > > output formats per data type.)
> >
> > Yea, that'd be *really* useful. It sucks that we basically require
> >
Hi,
On Fri, 9 Oct 2020 at 14:46, Andres Freund wrote:
> Hi,
>
> On 2020-10-08 09:46:38 +0200, Peter Eisentraut wrote:
> > New would be that the server would now also respond with a new message,
> say,
> >
> > S: DynamicResultInfo
>
> > Now, if the client has seen DynamicResultInfo earlier, it
Hi,
On 2020-10-08 09:46:38 +0200, Peter Eisentraut wrote:
> New would be that the server would now also respond with a new message, say,
>
> S: DynamicResultInfo
> Now, if the client has seen DynamicResultInfo earlier, it should now go into
> a new subsequence to get the remaining result sets,
On Fri, 9 Oct 2020 at 13:33, Andrew Dunstan wrote:
>
> On 10/8/20 3:46 AM, Peter Eisentraut wrote:
> > I want to progress work on stored procedures returning multiple result
> > sets. Examples of how this could work on the SQL side have previously
> > been shown [0]. We also have ongoing work
On 10/8/20 3:46 AM, Peter Eisentraut wrote:
> I want to progress work on stored procedures returning multiple result
> sets. Examples of how this could work on the SQL side have previously
> been shown [0]. We also have ongoing work to make psql show multiple
> result sets [1]. This appears
On 2020-10-08 10:23, Tatsuo Ishii wrote:
Are you proposing to bump up the protocol version (either major or
minor)? I am asking because it seems you are going to introduce some
new message types.
It wouldn't be a new major version. It could either be a new minor
version, or it would be
Are you proposing to bump up the protocol version (either major or
minor)? I am asking because it seems you are going to introduce some
new message types.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
> I want to
I want to progress work on stored procedures returning multiple result
sets. Examples of how this could work on the SQL side have previously
been shown [0]. We also have ongoing work to make psql show multiple
result sets [1]. This appears to work fine in the simple query
protocol. But the
36 matches
Mail list logo
