From: | Dave Cramer <davecramer(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: CommandStatus from insert returning when using a portal. |
Date: | 2023-07-12 21:59:29 |
Message-ID: | CADK3HHJPfbwn3-dTDDxCd4qQXHCt7KH4yuuxV37F6c-FkDBWgA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, 12 Jul 2023 at 17:49, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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
>
> Umm ... you do realize that we return the rows on-the-fly?
>
I do realize that.
> The server does not know how many rows got inserted/returned
>
Well I haven't looked at the code, but it seems unintuitive that adding the
returning clause changes the semantics of insert.
until it's run the query to completion, at which point all
> the data has already been sent to the client. There isn't
> any way to return the rowcount before the data, and it wouldn't
> be some trivial protocol adjustment to make that work differently.
> (What it *would* be is expensive, because we'd have to store
> those rows somewhere.)
>
I wasn't asking for that, I just want the number of rows inserted.
Thanks,
Dave
From | Date | Subject | |
---|---|---|---|
Next Message | David G. Johnston | 2023-07-12 22:12:50 | Re: CommandStatus from insert returning when using a portal. |
Previous Message | Tom Lane | 2023-07-12 21:49:23 | Re: CommandStatus from insert returning when using a portal. |