Re: CommandStatus from insert returning when using a portal. - Mailing list pgsql-hackers

From David G. Johnston
Subject Re: CommandStatus from insert returning when using a portal.
Date
Msg-id CAKFQuwaMLO5XE9kp=tecD+FmLzeHy-s8f4OJogm3PvWu=dZQUA@mail.gmail.com
Whole thread Raw
In response to Re: CommandStatus from insert returning when using a portal.  (Dave Cramer <davecramer@gmail.com>)
Responses Re: CommandStatus from insert returning when using a portal.
List pgsql-hackers
On Fri, Jul 14, 2023 at 9:30 AM Dave Cramer <davecramer@gmail.com> wrote:
David, 

I will try to get a tcpdump file. Doing this in libpq seems challenging as I'm not aware of how to create a portal in psql.

Yeah, apparently psql does something special (like ignoring it...) with its FETCH_COUNT variable (set to 2 below as evidenced by the first query) for the insert returning case.  As documented since the command itself is not select or values the test in is_select_command returns false and the branch:

 else if (pset.fetch_count <= 0 || pset.gexec_flag ||
pset.crosstab_flag || !is_select_command(query))
{
/* Default fetch-it-all-and-print mode */

Is chosen.

Fixing that test in some manner and recompiling psql seems like it should be the easiest way to produce a core-only test case.

postgres=# select * from (Values (1),(2),(30000),(40000)) vals (v);
 v
---
 1
 2
 30000
 40000
(4 rows)

postgres=# \bind 5 6 70000 80000
postgres=# insert into ins values ($1),($2),($3),($4) returning id;
  id
-------
     5
     6
 70000
 80000
(4 rows)

INSERT 0 4

I was hoping to see the INSERT RETURNING query have a 4 width header instead of 7.

David J.

pgsql-hackers by date:

Previous
From: Dave Cramer
Date:
Subject: Re: CommandStatus from insert returning when using a portal.
Next
From: "David G. Johnston"
Date:
Subject: Re: CommandStatus from insert returning when using a portal.