Hi Jelte, Thank you for comments and advises.
> From: Jelte Fennema-Nio <postg...@jeltef.nl> > Sent: Monday, July 8, 2024 5:31 PM > On Sun, 7 Jul 2024 at 23:46, fujii.y...@df.mitsubishielectric.co.jp > <fujii.y...@df.mitsubishielectric.co.jp> wrote: > > In my mind, Approach1 is superior. Therefore, if there are no objections > > this week, I plan to resume implementing > Approach1 next week. I would appreciate it if anyone could discuss the topic > with me or ask questions. > > Honestly, the more I think about this, the more I like Approach2. Not because > I disagree with you about some of the > limitations of Approach2, but because I'd rather see those limitations fixed > in CREATE TYPE, instead of working around > these limitations in CREATE AGGREGATE. That way more usages can benefit. > Detailed explanation and arguments below. Firstly, I may have jumped to conclusions too quickly. I apologize that. I would appreciate it if we clarify Approach 1 and Approach 2 more precisely and we can proceed with the discussion. Before we get into the details, let me break down the main differences between Approach 1 and Approach 2. The best thing about Approach2 is that it lets us send state values using the existing data type system. I'm worried that if we choose Approach2, we might face some limits because we have to create new types. But, we might be able to fix these limits if we look into it more. Approach1 doesn't make new types, so we can avoid these limits. But, it means we have to make export/import functions that are similar to the typsend/typreceive functions. So, we need to make sure if we really need this method. Is this the right understanding? > From: Jelte Fennema-Nio <postg...@jeltef.nl> > Sent: Monday, July 8, 2024 5:59 PM > On Sun, 30 Jun 2024 at 23:42, fujii.y...@df.mitsubishielectric.co.jp > <fujii.y...@df.mitsubishielectric.co.jp> wrote: > > Instead, I can make PARTIAL_AGGREGATE an unreserved word by placing it > > after the FILTER clause, like avg(c1) FILTER > (WHERE c2 > 0) PARTIAL_AGGREGATE, and by marking it as an ASLABEL word like > FILTER. > > I attached the patch of the method. > > If there are no objections, I would like to proceed with the method > > described above. > > I'd appreciate it if anyone comment the method. > > I like this approach of using PARTIAL_AGGREGATE in the same place as the > FILTER clause. Thank you for comment. > On Sun, 7 Jul 2024 at 23:52, fujii.y...@df.mitsubishielectric.co.jp > <fujii.y...@df.mitsubishielectric.co.jp> wrote: > > My plan for advancing the patch involves the following steps: > > Step1. Decide the approach on transmitting state value. > > Step2. Implement code (including comments) and tests to support a subset > > of aggregate functions. > > Specifically, I plan to support avg, sum, and other aggregate functions > > like min and max which don't need > export/import functions. > > Step3. Add documentations. > > > > To clarify my approach, should I proceed with Step 3 before Step2? > > (my opinion, Bruce might have a different one) > > I think it's good that you split the original patch in two: > 0001: non-internal partial aggregates > 0002: internal partial aggregates > > I think we're aligned on the general design of 0001. So I think now is > definitely the time to include documentation there, so > we can discuss this patch in more detail, and move it forward. > > I think generally for 0002 it would also be useful to have documentation, I > personally like reading it to understand the > general design and then comparing that to the code. But I also understand > that the language differences between Japanese > and English, makes writing such docs a significant effort for you. So I think > it would be fine to skip docs for 0002 for now > until we decide on the approach we want to take for internal partial > aggregates. At least for 0001, it seems like it would be a good idea to attach a document at this stage. Best regards, Yuki Fujii -- Yuki Fujii Information Technology R&D Center, Mitsubishi Electric Corporation
