postgresSQL Extended Query执行过程和sharding-proxy的处理
pg Extended Query
PostgreSQL: Documentation: 15: 55.2. Message Flow
多个阶段，可复用
Parse → DESCRIBE statement → SYNC
- Parse 解析， 将 sql 文本字符串，解析成 named preparedStatement 语句（生命周期随session） 占位符和参数类型
- Describe 获取元数据，返回 pst 参数描述符 parameterDescription 和 结果集的行描述符 RowDescription
由于此时 还没执行 Bind，还未将语句传输到backend 执行，RowDescription中列的传输格式 codec format 还是0 ； 参数的类型应该也只是根据客户端传到 frontend 指定的类型来的？ - Sync 发完一串 extended messages 后需要发一个 sync 表示结束, 服务端一起处理；
针对 sync 消息，服务端返回是否在事务中执行的状态 ‘T’ 在事务内， ‘I’ 不在事务内
BIND → DESCRIBE portal → EXECUTE → SYNC
a
bind
step, which creates a portal given a prepared statement and values for any needed parameters; and an
execute
step that runs a portal's query
- bind
绑定阶段 创建好一个可执行的
portal
, 包括参数元数据、返回结果集的元数据 （row 字段的pg类型 typeOid, 类型长度、 传输方式 0-text, 1-binary 等) 参数值 - DESCRIBE portal；此时是发到 backend 来获取元数据的，入参和查询结果的元数据 才是真实的
- execute
阶段 执行并获取结果集， 客户端可以根据上一步 describe portal 拿到的 rowDescription 中列的 format 来决定是用 0-text 还是 1-binary 要求服务端对参数和查询结果集中的字段值进行 format 后传输
同一个session里边，步骤一执行过后 如果是 named portal ，后续就可以直接执行步骤二
步骤一执行完后, frontend session 缓存好命名 pst， 下次同一个session再执行就能直接 走步骤二就可以了
sharding-proxy 执行日志
步骤一
‘P’ Parse stmtcache_1 sql
‘D’ ‘S’ Describe preparedStatement
[DEBUG] 2023-04-07 17:16:53.166 [nioEventLoopGroup-3-3] o.a.s.db.protocol.codec.PacketCodec - Read from client a3f6d846 :
+-------------------------------------------------+
| 0 1 2 3 4 5 6 7 8 9 a b c d e f |
+--------+-------------------------------------------------+----------------+
|00000000| 50 00 00 00 aa 73 74 6d 74 63 61 63 68 65 5f 31 |**P**....stmtcache_1|
|00000010| 00 53 45 4c 45 43 54 20 22 69 64 22 2c 22 73 74 |.SELECT "id","st|
|00000020| 75 64 65 6e 74 5f 6e 61 6d 65 22 20 46 52 4f 4d |udent_name" FROM|
|00000030| 20 22 74 5f 73 74 75 64 65 6e 74 5f 69 6e 66 6f | "t_student_info|
|00000040| 22 20 57 48 45 52 45 20 22 74 5f 73 74 75 64 65 |" WHERE "t_stude|
|00000050| 6e 74 5f 69 6e 66 6f 22 2e 22 69 64 22 20 3d 20 |nt_info"."id" = |
|00000060| 24 31 20 41 4e 44 20 22 74 5f 73 74 75 64 65 6e |$1 AND "t_studen|
|00000070| 74 5f 69 6e 66 6f 22 2e 22 69 64 22 20 3d 20 24 |t_info"."id" = $|
|00000080| 32 20 4f 52 44 45 52 20 42 59 20 22 74 5f 73 74 |2 ORDER BY "t_st|
|00000090| 75 64 65 6e 74 5f 69 6e 66 6f 22 2e 22 69 64 22 |udent_info"."id"|
|000000a0| 20 4c 49 4d 49 54 20 31 00 00 00 44 00 00 00 11 | LIMIT 1...**D**....|
|000000b0| 53 73 74 6d 74 63 61 63 68 65 5f 31 00 53 00 00 |**S**stmtcache_1.**S**..|
|000000c0| 00 04 |.. |
+--------+-------------------------------------------------+----------------+
请求报文 解析成对应的 packet 对象 xxPacket，并创建对应的执行器 xxExecutor
执行结果
此时 rowDescription, dataFormat都是0
步骤二
‘B’ Bind
‘D’ + ‘P’ Describe porta
‘E’ Execute
‘S’ Sync
[DEBUG] 2023-04-07 17:16:53.304 [nioEventLoopGroup-3-3] o.a.s.db.protocol.codec.PacketCodec - Read from client a3f6d846 :
+-------------------------------------------------+
| 0 1 2 3 4 5 6 7 8 9 a b c d e f |
+--------+-------------------------------------------------+----------------+
|00000000| 42 00 00 00 37 00 73 74 6d 74 63 61 63 68 65 5f |**B**...7.stmtcache_|
|00000010| 31 00 00 02 00 01 00 01 00 02 00 00 00 08 00 00 |1...............|
|00000020| 00 00 00 00 00 16 00 00 00 08 00 00 00 00 00 00 |................|
|00000030| 00 16 00 02 00 01 00 00 44 00 00 00 06 50 00 45 |........**D**....P.**E**|
|00000040| 00 00 00 09 00 00 00 00 00 53 00 00 00 04 |.........**S**.... |
报文解析，和对应执行器构建
响应报文
RowDescription 响应结果集的行描述符，DataRowPacket 响应行数据
列 id ，值是 binary 格式 对应 columnDescription 的 dataFormat = 1 (binary)