| From: | Chapman Flack <chap(at)anastigmatix(dot)net> |
|---|---|
| To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
| 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:39:27 |
| Message-ID: | a0da38378cd9d986f1521280a81cf0f7@anastigmatix.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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 not only any auto-generated column but also
> the
> set of columns that provide the unique natural key.
Yikes!
That sounds like something that (if it's feasible) the driver's
rewriting for RETURN_GENERATED_KEYS should try to do ... the
driver is already expected to be smart enough to know which
columns the generated keys are ... should it also try to rewrite
the query in some way to get a meaningful order of the results?
But then ... the apidoc for getGeneratedKeys is completely
silent on the ordering anyway. I get the feeling this whole
corner of the JDBC API may have been thought out only as far
as issuing a single-row INSERT at a time and getting its
assigned keys back.
Regards,
-Chap
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nathan Bossart | 2023-07-14 23:34:28 | Re: Should we remove db_user_namespace? |
| Previous Message | David G. Johnston | 2023-07-14 22:22:34 | Re: CommandStatus from insert returning when using a portal. |