On Thu, Nov 22, 2018 at 7:51 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > On Thu, Nov 22, 2018 at 7:48 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > > > On Thu, Nov 22, 2018 at 7:02 PM Alvaro Herrera <alvhe...@2ndquadrant.com> > > wrote: > > > > > > On 2018-Nov-20, Haribabu Kommi wrote: > > > > > > > > > 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. > > > > > > > > > > Hmm, can we use 0 as default value without any such caveat? > > > > > > > > Yes, with strict and 0 as default value can work. > > > > If there is no problem, I can go ahead with the above changes? > > > > > > I'm not sure I understand this proposal. Does this mean that passing -1 > > > as databaseid / userid would match all databases/users, and passing 0 as > > > queryid would match all queries? > > > > > > > No, for userid/databaseid also it will be 0 (aka InvalidOid). > > > > Not sure if the above statement is clear, but what I wanted to say > was "for all the three userid/databaseid/queryid, default will be 0 > (aka InvalidOid)." >
Is the proposal clear? If so, can you please share your opinion even if it is the same as previous, because, I think that will help us in moving forward with this patch. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
