Hi!
>
> I'm not sure if we have prior art for expressing bitflags in Postgres
> envvars, other than maybe PGREQUIREAUTH. A comma-separated list would
> be easy to do. We could name these things according to whether
> they're
> unsafe or not, like
>
> PGOAUTHDEBUG=UNSAFE-http,UNSAFE-trace,print-counts
>
> Or maybe that's too verbose, and we could say that to use any of the
> unsafe options, you have to say it up front:
>
> # http and trace are dangerous
> PGOAUTHDEBUG=UNSAFE:http,trace,print-counts
> # these two are safe
> PGOAUTHDEBUG=print-counts,print-plugin-errors
>
> Or something else? Since this is developer-facing, I don't think it
> has to necessarily be intuitive for end users, as long as the lack of
> safety remains obvious to them. We can just focus on ergonomics for
> us.
I will for sure try to avoid this kind of format with comma separated
options, this mainly because are really hard to parse and manage in an
automated way, and sometimes, are hard to read when there's too many
options, and at some point, there could be many options since the flows
can start getting really complicated.
Why not keep something with debug levels? Even if it sounds really
classic, for parsing reasons are really good.
Now, if what is required it's counts or HTTP calls, probably this could
be like a "flow debug" an option like "PGOAUTHFLOWDEBUG" that depending
on the levels (info, debug, trace) can print from the hosts and/or url
calls, to the headers sent and received from the hosts.
The debug of a flow can be an entire set of levels due to the current
complexity and that may or may not increase in time, what do you think?
