| From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
|---|---|
| To: | Chapman Flack <chap(at)anastigmatix(dot)net> |
| Cc: | Dave Cramer <davecramer(at)gmail(dot)com>, 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-14 22:22:34 |
| Message-ID: | CAKFQuwYioZVjVo-j57AWRScG6ics9E837ESGcksDYRJcP4wwXQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Jul 14, 2023 at 3:12 PM Chapman Flack <chap(at)anastigmatix(dot)net> 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 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 not only any auto-generated column but also the
set of columns that provide the unique natural key.
David J.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Chapman Flack | 2023-07-14 22:39:27 | Re: CommandStatus from insert returning when using a portal. |
| Previous Message | Jacob Champion | 2023-07-14 22:20:39 | Re: pg_dump needs SELECT privileges on irrelevant extension table |