| From: | Dave Cramer <davecramer(at)gmail(dot)com> |
|---|---|
| To: | chap(at)anastigmatix(dot)net |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: CommandStatus from insert returning when using a portal. |
| Date: | 2023-07-13 00:57:20 |
| Message-ID: | CADK3HH+gDcwgGO6N=8MuGB8rtZ3MruQY1rVFJT+yE27H6pnLmQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
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 INSERT 2 0
Dave
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Masahiro Ikeda | 2023-07-13 01:26:35 | Re: Support to define custom wait events for extensions |
| Previous Message | Matheus Alcantara | 2023-07-13 00:22:13 | Duplicated LLVMJitHandle->lljit assignment? |