On Mon, Nov 19, 2018 at 10:48 AM Haribabu Kommi <kommi.haribabu@gmail.com> wrote: > > On Mon, Nov 19, 2018 at 1:37 PM Alvaro Herrera <alvherre@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.
If you want more input ont it, I'd vote for either 2 or 4. Between those two I think I have a slight favor in the direction of 2, but really not enough to voice strongly. I do feel more strongly that 1 and 3 are not good options.