Hi. Bruce, Robert, Tom, Alexander, hackers.
Apologies for the late response.
Thanks to Bruce, I had the opportunity to have individual discussions with Robert and Tom at PGConf.dev 2024.
I'm truly grateful to Bruce, Robert, and Tom for their time.
I've attached the presentation slides used during our discussions.
Below is a summary of our conversations.
As my English is not perfect, there may be some misunderstandings.
If so, I apologize and would appreciate any corrections or comments.
[Summary]
Basically, I will make the prototype as the presentation slides.
In specialty, the prototype has the following two limits.
Limit1. The server versions of the coordinator and the worker match.
Limit2. Supported built-in aggregate functions are a few subset
(Ex. avg, sum, count).
However, there are many build-in aggregate functions in which import and export functions are not necessary.
(See p.18 in the presentation slides).
I will support these aggregate functions.
In this prototype, It is necessary for the following requirements.
Requirement1. Ensure the compatibility even if the server setting(Ex. encodings) of the coordinator and the worker
aredifferent. (with Tom)
Requirement2. Consider appropriate position of the new keyword "PARTIAL_AGGREGATE". (with Robert)
Existing patch: Before the target expression. Ex. avg(PARTIAL_AGGREGATE c1)
Ideal: Before the aggregate function. Ex. PARTIAL_AGGREGATE avg(c1)
Requirement3. Consider to avoid to make the new keyword "PARTIAL_AGGREGATE" become a reserved word. (with Robert)
In the existing patch, "PARTIAL_AGGREGATE" is a reserved word.
In addition to the summary,
I will add sufficient document and comments to the next patch as Bruce and Robert said.
And, I will fix the problem as Alexander pointed in the last week.
Sincerely yours,
Yuuki Fujii
--
Yuuki Fujii
Information Technology R&D Center Mitsubishi Electric Corporation
