Re: CommandStatus from insert returning when using a portal.

On Wed, 12 Jul 2023 at 21:31, David G. Johnston <david(dot)g(dot)johnston(at)gmail(dot)com>
wrote:

> On Wed, Jul 12, 2023 at 5:57 PM Dave Cramer <davecramer(at)gmail(dot)com> wrote:
>
>> On Wed, 12 Jul 2023 at 20:00, <chap(at)anastigmatix(dot)net> wrote:
>>
>>> Dave Cramer <davecramer(at)gmail(dot)com> 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 an INSERT RETURNING?
>>>
>>
>> It's really executeUpdate which is supposed to return the number of rows
>> updated.
>>
>
> 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. executeQuery is the method to use. And execute() should
> behave as if executeQuery was called, i.e., return true, which it is
> capable of doing since it has resultSet data that it needs to handle.
>
> The addition of returning turns the insert/update/delete into a select in
> terms of effective client-seen behavior.
>
> ISTM that you are trying to make user-error less painful. While that is
> laudable it apparently isn't practical. They can either discard the
> results and get a count by omitting returning or obtain the result and
> derive the count by counting rows alongside whatever else they needed the
> returned data for.
>
Any comment on why the CommandComplete is incorrect ?
It returns INSERT 0 0 if a cursor is used

Dave

>