On Mon, Nov 12, 2018 at 10:55 AM Haribabu Kommi <kommi.harib...@gmail.com> wrote: > > On Fri, Nov 9, 2018 at 2:12 PM Amit Kapila <amit.kapil...@gmail.com> wrote: >> >> On Thu, Nov 8, 2018 at 10:56 PM Magnus Hagander <mag...@hagander.net> wrote: >> > >> > On Thu, Nov 8, 2018 at 3:53 PM Sergei Kornilov <s...@zsrv.org> wrote: >> >> >> >> Hi >> >> >> >> >> Sure, but what are we going to achieve with that number? What >> >> >> information user is going to get by that? If it can help us to ensure >> >> >> that it has reset the expected number of statements, then I can see >> >> >> the clear usage, but without that, the return value doesn't seem to >> >> >> have any clear purpose. So, I don't see much value in breaking >> >> >> compatibility. >> >> >> >> >> >> Does anyone else have an opinion on this matter? >> >> > >> >> > This was proposed by Sergei Kornilov in >> >> > https://postgr.es/m/3368121530260...@web21g.yandex.ru saying that "it >> >> > would be nice" to return it. Maybe he has an use case in mind? I don't >> >> > see one myself. >> >> No, i have no specific usecase for this. Silently remove all matching >> >> rows and return void is ok for me. But i still think LOG ereport is not >> >> useful. >> > >> > >> > I would much prefer it to be a return code rather than a forced LOG >> > message. Log message spam is very much a thing, and things that are logged >> > as LOG will always be there. >> > >> >> Is any such LOG message present in the latest patch? I agree that the >> return code might be better, but there doesn't exist any such (LOG) >> thing. I see that it can be helpful for some users if we have any >> such return code, but don't know if it doesn't already exist, why that >> should be a requirement for this patch? Do you have any strong >> opinion about introducing return code with this patch? > > > I thought that returning the affected number of statements with the change > of adding new parameters to the reset function will be helpful to find out > how many statements are affected? >
It is not clear how will user make use of that information. > I can revert it back to void, > +1, as we don't see any good reason to break backward compatibility. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
