On Wed, Jul 12, 2023 at 2:49 PM Tom Lane wrote:
> Dave Cramer writes:
> > Obviously I am biased by the JDBC API which would like to have
> > PreparedStatement.execute() return the number of rows inserted
> > without having to wait to read all of the rows returned
>
> Umm ... you do realize that
On 2023-Jul-14, Dave Cramer wrote:
> David,
>
> I will try to get a tcpdump file. Doing this in libpq seems challenging as
> I'm not aware of how to create a portal in psql.
You can probably have a look at src/test/modules/libpq_pipeline/libpq_pipeline.c
as a basis to write some test code for
On 2023-07-14 18:22, David G. Johnston wrote:
For PostgreSQL this is even moreso (i.e, huge means count > 1) since
the
order of rows in the returning clause is not promised to be related to
the
order of the rows as seen in the supplied insert command. A manual
insert
returning should ask for
On Fri, Jul 14, 2023 at 3:12 PM Chapman Flack wrote:
> If someone really does want to do a huge INSERT and get the generated
> values back in increments, it might be clearer to write an explicit
> INSERT RETURNING and issue it with executeQuery, where everything will
> work as expected.
>
>
For
On 2023-07-14 17:31, Chapman Flack wrote:
So when getGeneratedKeys was later added, a way of getting a ResultSet
after an executeUpdate, did they consciously intend it to come under
the jurisdiction of existing apidoc that concerned the fetch size of
a ResultSet you wanted from executeQuery?
...
On Fri, Jul 14, 2023 at 12:51 PM Tom Lane wrote:
> "David G. Johnston" writes:
> > I agree that the documented contract of the insert command tag says it
> > reports the size of the entire tuple store maintained by the server
> during
> > the transaction instead of just the most recent count on
On 2023-07-14 17:02, Dave Cramer wrote:
The fly in the ointment here is when they setFetchSize and we decide to
use a Portal under the covers.
A person might language-lawyer about whether setFetchSize even applies
to the kind of thing done with executeUpdate.
Hmm ... the apidoc for
On Fri, 14 Jul 2023 at 16:32, wrote:
> On 2023-07-14 15:49, Dave Cramer wrote:
> > On Fri, 14 Jul 2023 at 15:40, wrote:
> >> Perhaps an easy rule would be, if the driver itself adds RETURNING
> >> because of a RETURN_GENERATED_KEYS option, it should also force the
> >> fetch count to zero and
On 2023-07-14 15:49, Dave Cramer wrote:
On Fri, 14 Jul 2023 at 15:40, wrote:
Perhaps an easy rule would be, if the driver itself adds RETURNING
because of a RETURN_GENERATED_KEYS option, it should also force the
fetch count to zero and collect all the returned rows before
executeUpdate
"David G. Johnston" writes:
> I agree that the documented contract of the insert command tag says it
> reports the size of the entire tuple store maintained by the server during
> the transaction instead of just the most recent count on subsequent fetches.
Where do you see that documented,
On Fri, 14 Jul 2023 at 15:40, wrote:
> On 2023-07-14 14:19, David G. Johnston wrote:
> > Because of the returning they all need a portal so far as the server is
> > concerned and the server will obligingly send the contents of the
> > portal
> > back to the client.
>
> Dave's pcap file, for the
On 2023-07-14 14:19, David G. Johnston wrote:
Because of the returning they all need a portal so far as the server is
concerned and the server will obligingly send the contents of the
portal
back to the client.
Dave's pcap file, for the fetch count 0 case, does not show any
portal name used
On Fri, Jul 14, 2023 at 11:34 AM wrote:
> On 2023-07-12 21:30, David G. Johnston wrote:
> > Right, and executeUpdate is the wrong API method to use, in the
> > PostgreSQL
> > world, when executing insert/update/delete with the non-SQL-standard
> > returning clause. ... ISTM that you are trying
On Fri, 14 Jul 2023 at 14:34, wrote:
> On 2023-07-12 21:30, David G. Johnston wrote:
> > Right, and executeUpdate is the wrong API method to use, in the
> > PostgreSQL
> > world, when executing insert/update/delete with the non-SQL-standard
> > returning clause. ... ISTM that you are trying to
On 2023-07-14 14:19, David G. Johnston wrote:
Is there some magic set of arguments I should be using besides: tcpdump
-Ar
filename ?
I opened it with Wireshark, which has a pgsql protocol decoder.
Regards,
-Chap
On 2023-07-12 21:30, David G. Johnston wrote:
Right, and executeUpdate is the wrong API method to use, in the
PostgreSQL
world, when executing insert/update/delete with the non-SQL-standard
returning clause. ... ISTM that you are trying to make user-error less
painful.
In Dave's Java
On Fri, Jul 14, 2023 at 10:39 AM wrote:
> On 2023-07-14 12:58, Dave Cramer wrote:
> > See attached pcap file
>
> So if the fetch count is zero and no portal is needed,
> or if the fetch count exceeds the row count and the command
> completion follows directly with no suspension of the portal,
On Fri, 14 Jul 2023 at 13:39, wrote:
> On 2023-07-14 12:58, Dave Cramer wrote:
> > See attached pcap file
>
> So if the fetch count is zero and no portal is needed,
> or if the fetch count exceeds the row count and the command
> completion follows directly with no suspension of the portal, then
On 2023-07-14 12:58, Dave Cramer wrote:
See attached pcap file
So if the fetch count is zero and no portal is needed,
or if the fetch count exceeds the row count and the command
completion follows directly with no suspension of the portal, then
it comes with the correct count, but if the
See attached pcap file
after the execute of the portal it returns INSERT 0 0
Dave Cramer
On Fri, 14 Jul 2023 at 12:57, David G. Johnston
wrote:
> On Fri, Jul 14, 2023 at 9:50 AM David G. Johnston <
> david.g.johns...@gmail.com> wrote:
>
>>
>> Fixing that test in some manner and recompiling
On Fri, Jul 14, 2023 at 9:50 AM David G. Johnston <
david.g.johns...@gmail.com> wrote:
>
> Fixing that test in some manner and recompiling psql seems like it should
> be the easiest way to produce a core-only test case.
>
>
Apparently not - since it (ExecQueryUsingCursor) literally wraps the
On Fri, Jul 14, 2023 at 9:30 AM Dave Cramer wrote:
> David,
>
> I will try to get a tcpdump file. Doing this in libpq seems challenging as
> I'm not aware of how to create a portal in psql.
>
Yeah, apparently psql does something special (like ignoring it...) with its
FETCH_COUNT variable (set
David,
I will try to get a tcpdump file. Doing this in libpq seems challenging as
I'm not aware of how to create a portal in psql.
Chap
The only difference is one instance uses a portal to fetch the results, the
other (correct one) is a normal insert where all of the rows are returned
On 2023-07-12 20:57, Dave Cramer wrote:
Without a cursor it returns right away as all of the results are
returned
by the server. However with cursor you have to wait until you fetch the
rows before you can get the CommandComplete message which btw is wrong
as
it returns INSERT 0 0 instead of
On Thu, Jul 13, 2023 at 6:07 PM Dave Cramer wrote:
> On Thu, 13 Jul 2023 at 10:24, David G. Johnston <
> david.g.johns...@gmail.com> wrote:
>
>> On Thursday, July 13, 2023, Dave Cramer wrote:
>>
>>>
>>> Any comment on why the CommandComplete is incorrect ?
>>> It returns INSERT 0 0 if a cursor
On Thu, 13 Jul 2023 at 10:24, David G. Johnston
wrote:
> On Thursday, July 13, 2023, Dave Cramer wrote:
>
>>
>> Any comment on why the CommandComplete is incorrect ?
>> It returns INSERT 0 0 if a cursor is used
>>
>
> Looking at DECLARE it is surprising that what you describe is even
>
On Thursday, July 13, 2023, Dave Cramer wrote:
>
> Any comment on why the CommandComplete is incorrect ?
> It returns INSERT 0 0 if a cursor is used
>
Looking at DECLARE it is surprising that what you describe is even
possible. Can you share a psql reproducer?
David J.
On Wed, 12 Jul 2023 at 21:31, David G. Johnston
wrote:
> On Wed, Jul 12, 2023 at 5:57 PM Dave Cramer wrote:
>
>> On Wed, 12 Jul 2023 at 20:00, wrote:
>>
>>> Dave Cramer writes:
>>> > Obviously I am biased by the JDBC API which would like to have
>>> > PreparedStatement.execute() return the
On Wed, Jul 12, 2023 at 5:57 PM Dave Cramer wrote:
> On Wed, 12 Jul 2023 at 20:00, wrote:
>
>> Dave Cramer writes:
>> > Obviously I am biased by the JDBC API which would like to have
>> > PreparedStatement.execute() return the number of rows inserted
>> > without having to wait to read all of
On Wed, 12 Jul 2023 at 20:00, wrote:
> Dave Cramer writes:
> > Obviously I am biased by the JDBC API which would like to have
> > PreparedStatement.execute() return the number of rows inserted
> > without having to wait to read all of the rows returned
>
> Huh ... just how *is*
Dave Cramer writes:
Obviously I am biased by the JDBC API which would like to have
PreparedStatement.execute() return the number of rows inserted
without having to wait to read all of the rows returned
Huh ... just how *is* PreparedStatement.execute() supposed
to behave when the statement is
On Wed, Jul 12, 2023 at 2:59 PM Dave Cramer wrote:
> On Wed, 12 Jul 2023 at 17:49, Tom Lane wrote:
>
>> Dave Cramer writes:
>> > Obviously I am biased by the JDBC API which would like to have
>> > PreparedStatement.execute() return the number of rows inserted
>> > without having to wait to
On Wed, 12 Jul 2023 at 17:49, Tom Lane wrote:
> Dave Cramer writes:
> > Obviously I am biased by the JDBC API which would like to have
> > PreparedStatement.execute() return the number of rows inserted
> > without having to wait to read all of the rows returned
>
> Umm ... you do realize that
Dave Cramer writes:
> Obviously I am biased by the JDBC API which would like to have
> PreparedStatement.execute() return the number of rows inserted
> without having to wait to read all of the rows returned
Umm ... you do realize that we return the rows on-the-fly?
The server does not know how
Dave Cramer
On Wed, 12 Jul 2023 at 16:31, David G. Johnston
wrote:
> On Wed, Jul 12, 2023 at 1:03 PM Dave Cramer wrote:
>
>>
>> INSERT INTO test_table (cnt) VALUES (1), (2) RETURNING id
>>
>> if a portal is used to get the results then the CommandStatus
>>
>
> IIUC the portal is not optional
On Wed, Jul 12, 2023 at 1:03 PM Dave Cramer wrote:
>
> With a simple insert such as
>
> INSERT INTO test_table (cnt) VALUES (1), (2) RETURNING id
>
> if a portal is used to get the results then the CommandStatus is not returned
> on the execute only when the portal is closed. After looking at
On Wed, Jul 12, 2023 at 1:03 PM Dave Cramer wrote:
>
> INSERT INTO test_table (cnt) VALUES (1), (2) RETURNING id
>
> if a portal is used to get the results then the CommandStatus
>
IIUC the portal is not optional if you including the RETURNING clause.
There is no CommandStatus message in the
Greetings,
With a simple insert such as
INSERT INTO test_table (cnt) VALUES (1), (2) RETURNING id
if a portal is used to get the results then the CommandStatus is not
returned on the execute only when the portal is closed. After looking at
this more it is really after all of the data is read
38 matches
Mail list logo
