Re: PGEventProcs must not be allowed to break libpq

2022-02-17 Thread Tom Lane
Alvaro Herrera writes: > Not really related to this complaint and patch, but as far as I can see, > libpq events go completely untested in the core source. Maybe we should > come up with a test module or something? Yeah, I suppose. The libpq part of it is pretty simple, but still...

Re: PGEventProcs must not be allowed to break libpq

2022-02-17 Thread Alvaro Herrera
Not really related to this complaint and patch, but as far as I can see, libpq events go completely untested in the core source. Maybe we should come up with a test module or something? -- Álvaro Herrera 39°49'30"S 73°17'W — https://www.EnterpriseDB.com/

Re: PGEventProcs must not be allowed to break libpq

2022-02-16 Thread Tom Lane
I wrote: > ... more generally, it seems to me that allowing a failing PGEventProc > to cause this to happen is just not sane. It breaks absolutely > every guarantee you might think we have about how libpq will behave. > As an example that seems very plausible currently, if an event proc > doesn't

PGEventProcs must not be allowed to break libpq

2022-02-15 Thread Tom Lane
I've been fooling around with the duplicated-error-text issue discussed in [1], and I think I have a solution that is fairly bulletproof ... except that it cannot cope with this little gem at the bottom of PQgetResult: if (!res->events[i].proc(PGEVT_RESULTCREATE, &evt,