On 2023-Nov-07, Jelte Fennema-Nio wrote: > I think this function should be named something with the "PQsend" > prefix since that's the way we name all our public async message > sending functions in libpq. The "Put" word we only use in internal > libpq functions, so I feel it has no place in the external API > surface. My proposal would be to call the function PQsendPipelineSync > (i.e. having the PQsend prefix while still looking similar to the > existing PQpipelineSync).
Argued that way, it makes sense to me. > Also I think the flag argument is completely unnecessary. [...] > Instead of looking at it as adding another version of our current > PQpipelineSync API, we should look at it as an addition to our current > list of PQsend functions for a new packet type. And none of those > PQsend functions ever needed a flag. True. > Finally, I have one suggestion for a behavioural change: I think the > function should still call pqPipelineFlush, just like all of our other > PQsend functions (except PQsendFlushRequest, but that seems like an > oversight there too). I agree. So, yeah, it looks like this will be pretty similar to Anton's original patch, with PQpipelineSync() being just PQsendPipelineSync() + PQflush(). -- Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/ "In fact, the basic problem with Perl 5's subroutines is that they're not crufty enough, so the cruft leaks out into user-defined code instead, by the Conservation of Cruft Principle." (Larry Wall, Apocalypse 6)
