From: | Aleksander Alekseev <aleksander(at)timescale(dot)com> |
---|---|
To: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
Cc: | Vasilii Smirnov <vasilii(dot)smirnov(at)mailbox(dot)org> |
Subject: | Re: libpq: unexpected return code from PQexecParams with a DO INSTEAD rule present |
Date: | 2024-07-15 14:04:19 |
Message-ID: | CAJ7c6TOQLq912fU0su1hKpJy4_EyD8gat-=y6uxZVsc_30i7uw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2024-07-15 16:07:40 | Re: BUG #18531: err when using 'current of' with incremental COMMIT |
Previous Message | Tom Lane | 2024-07-15 13:55:28 | Re: BUG #17889: Invalid cursor direction for a foreign scan that reached the fetch_size (MOVE BACKWARD ALL IN cX) |