On 2018-02-22 20:30:02 +0100, Magnus Hagander wrote: > Complexity for the bgw usecase. It now has to construct a key/value pair > with proper escaping (well, for this one flag it would be easy, but if we > do that wouldn't we also support the other config params? Were you thinking > we'd have *just* tihs one?). Basically taking a data that you have in a > "structured format" in the btw already turning it to a string and then > parsing it back into structured data in the same string.
The serialization problem seems out of scope, I don't see why this code would need to deal with it. Receiving the options would be pretty easy, we pretty much have the relevant code for PGOPTIONS handling. The more important part I think is that we solve it via a GUC that can be used outside of bgworkers. Whether we require setting it via set_config() for bgworkers or have option parsing doesn't matter that much. > I think it'd be cleaner to let the bgw initializer pass those as flags. A > "user connection" parameter could still use the booelan in InitPostgres() > of course, and not invent a new things there, but the entry point API could > stay simpler. I'm pretty strongly against having a special case flag for bgw initialization for this. Greetings, Andres Freund
