On Mon, Nov 19, 2018 at 10:48 AM Haribabu Kommi <kommi.harib...@gmail.com> wrote: > > On Mon, Nov 19, 2018 at 1:37 PM Alvaro Herrera <alvhe...@2ndquadrant.com> > wrote: >> >> On 2018-Nov-19, Michael Paquier wrote: >> >> > On Mon, Nov 19, 2018 at 10:41:22AM +1100, Haribabu Kommi wrote: >> > > So 6 new functions needs to be added to cover all the above cases, >> > > IMO, we may need functions for all combinations, because I feel some >> > > user may have the requirement of left out combination, in case if we >> > > choose >> > > only some combinations. >> > >> > That's bloating the interface in my opinion. >> >> I understand. >> >> Let's call for a vote from a larger audience. It's important to get >> this interface right, ISTM. > > > Amit suggested another option in another mail, so total viable > solutions that are discussed as of now are, > > 1. Single API with NULL input treat as invalid value > 2. Multiple API to deal with NULL input of other values > 3. Single API with NULL value to treat them as current user, current database > and NULL queryid. > 4. Single API with -1 as invalid value, treat NULL as no matching. (Only > problem > with this approach is till now -1 is also a valid queryid, but setting -1 as > queryid > needs to be avoided. >
As discussed above the problem mentioned by Hari in point-4 won't be there if we use a default value as 0. > I prefer single API. I can go with either 3 or 4. > > opinion from others? We don't see many opinions from others, but what I can read here is the count: Option-3: Michael, Hari Option-4: Amit, Hari Option-2: Alvaro As Hari seems to be a bit more inclined towards option-4, I think we can proceed with it. Alvaro, we understand your concerns and it seems there is some genuine way to address that. Kindly let us know if you still see the issue or you are still not comfortable? If you are not comfortable with what is being proposed, kindly suggest a way forward for this patch? -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
