Re: dynamic result sets support in extended query protocol
От | Peter Eisentraut |
---|---|
Тема | Re: dynamic result sets support in extended query protocol |
Дата | |
Msg-id | 896e6e09-2304-4cff-d6ff-62176344b2f6@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: dynamic result sets support in extended query protocol (Peter Eisentraut <peter.eisentraut@enterprisedb.com>) |
Ответы |
Re: dynamic result sets support in extended query protocol
|
Список | pgsql-hackers |
On 31.01.23 12:07, Peter Eisentraut wrote: >> Applying this patch, your test queries seem to work correctly. > > Great! > >> This is quite WIP, especially because there's a couple of scenarios >> uncovered by tests that I'd like to ensure correctness about, but if you >> would like to continue adding tests for extended query and dynamic >> result sets, it may be helpful. > > I should note that it is debatable whether my patch extends the extended > query protocol or just uses it within its existing spec but in new ways. > It just happened to work in old libpq versions without any changes. So > you should keep that in mind as you refine your patch, since the way the > protocol has been extended/creatively-used is still subject to review. After some consideration, I have an idea how to proceed with this. I have split my original patch into two incremental patches. The first patch implements the original feature, but just for the simple query protocol. (The simple query protocol already supports multiple result sets.) Attempting to return dynamic result sets using the extended query protocol will result in an error. The second patch then adds the extended query protocol support back in, but it still has the issues with libpq that we are discussing. I think this way we could have a chance to get the first part into PG16 or early into PG17, and then the second part can be worked on with less stress. This would also allow us to consider a minor protocol version bump, and the handling of binary format for dynamic result sets (like https://commitfest.postgresql.org/42/3777/), and maybe some other issues. The attached patches are the same as before, rebased over master and split up as described. I haven't done any significant work on the contents, but I will try to get the 0001 patch into a more polished state soon.
Вложения
В списке pgsql-hackers по дате отправления: