Re: libpq: unexpected return code from PQexecParams with a DO INSTEAD rule present - Mailing list pgsql-bugs

Hi,

> Let's say I have a table "_users", and also a view "users" that excludes
> all soft-deleted records from that table:
>
> [...]

Thanks for the report. Here is what I discovered so far.

Took me some time to figure out exact steps to run the example (they
are different comparing to C code):

```
export PRFX=/home/eax/pginstall
g++ -g -Wall -o test_libpq -I$PRFX/include
-L$PRFX/lib/aarch64-linux-gnu/ test_libpq_soft_delete.cpp -lpq
LD_LIBRARY_PATH=$PRFX/lib/aarch64-linux-gnu/ ./test_libpq
```

Here is what is passed over the network in
`TEST(testDelete(usingPQExec, softDelete));` case:

```
192.168.88.36:34294 -> 192.168.88.36:5432, 53 (0x35) bytes

        00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

0000    51 00 00 00 34 0A 20 20 44 45 4C 45 54 45 20 46    Q...4.  DELETE F
0010    52 4F 4D 20 74 65 73 74 5F 6C 69 62 70 71 2E 75    ROM test_libpq.u
0020    73 65 72 73 0A 20 20 52 45 54 55 52 4E 49 4E 47    sers.  RETURNING
0030    20 69 64 0A 00                                      id..

192.168.88.36:5432 -> 192.168.88.36:34294, 60 (0x3c) bytes

        00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

0000    54 00 00 00 1B 00 01 69 64 00 00 00 00 00 00 00    T......id.......
0010    00 00 00 17 00 04 FF FF FF FF 00 00 44 00 00 00    ............D...
0020    0B 00 01 00 00 00 01 31 43 00 00 00 0D 44 45 4C    .......1C....DEL
0030    45 54 45 20 30 00 5A 00 00 00 05 49                ETE 0.Z....I
```

Note the second packet with PqMsg_RowDescription ('T') and
PqMsg_DataRow('D') messages. They contain the RETURNING ids (in this
case "1").

And here is `TEST(testDelete(usingPQExecParams, softDelete))`:

```
192.168.88.36:55166 -> 192.168.88.36:5432, 93 (0x5d) bytes

        00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

0000    50 00 00 00 37 00 0A 20 20 44 45 4C 45 54 45 20    P...7..  DELETE
0010    46 52 4F 4D 20 74 65 73 74 5F 6C 69 62 70 71 2E    FROM test_libpq.
0020    75 73 65 72 73 0A 20 20 52 45 54 55 52 4E 49 4E    users.  RETURNIN
0030    47 20 69 64 0A 00 00 00 42 00 00 00 0E 00 00 00    G id....B.......
0040    00 00 00 00 01 00 00 44 00 00 00 06 50 00 45 00    .......D....P.E.
0050    00 00 09 00 00 00 00 00 53 00 00 00 04             ........S....

192.168.88.36:5432 -> 192.168.88.36:55166, 35 (0x23) bytes

        00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

0000    31 00 00 00 04 32 00 00 00 04 6E 00 00 00 04 43    1....2....n....C
0010    00 00 00 0D 44 45 4C 45 54 45 20 30 00 5A 00 00    ....DELETE 0.Z..
0020    00 05 49                                           ..I
```

In this case libpq chooses extended query protocol (not 'P' and 'B'
packages - PqMsg_Parse and PqMsg_Bind messages). Then go "describe
portal", "execute" and "sync".

The server answers "parse complete" ('1'), "bind complete" ('2'), and
most importantly PqMsg_NoData ('n').

So far it seems to be an error somewhere in the protocol
implementation. Instead of NoData we should reply with DataRow.

-- 
Best regards,
Aleksander Alekseev