From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | Curt Kolovson <ckolovson(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-docs(at)lists(dot)postgresql(dot)org |
Subject: | Re: Bug in documentation: https://www.postgresql.org/docs/current/spi-examples.html |
Date: | 2023-07-18 03:13:41 |
Message-ID: | CAKFQuwZjEOJR8i7OLaxLxUCBR4aRU2PL_Xg1UFbUUkmPGxz73Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-docs |
On Mon, Jul 17, 2023 at 7:45 PM Curt Kolovson <ckolovson(at)gmail(dot)com> wrote:
> I’d vote for showing both (with RETURNING and without), since without it
> the second argument to SPI_exec has no effect in this example, which may
> not be obvious. That seems to be one of the subtle points illustrated by
> this example.
>
I concur:
=> SELECT execq('CREATE TABLE a (x integer)', 0); // start at 0
=> INSERT INTO a VALUES (execq('INSERT INTO a VALUES (0)', 0)); // insert 2
=> SELECT execq('SELECT * FROM a', 0);
+ => SELECT execq('INSERT INTO a SELECT x + 2 FROM a returning x', 1); --
one more
+ -- (IIUC non-deterministically regardless of observed behavior even if
there were a limit in the SELECT)
=> SELECT execq('INSERT INTO a SELECT x + 2 FROM a', 1); // three more
=> SELECT execq('SELECT * FROM a', 10); // 6 as 10 is a limit
...[next block]
David J.
From | Date | Subject | |
---|---|---|---|
Next Message | PG Doc comments form | 2023-07-18 11:43:44 | IN for records |
Previous Message | Curt Kolovson | 2023-07-18 02:45:24 | Re: Bug in documentation: https://www.postgresql.org/docs/current/spi-examples.html |