On Thu, Jun 13, 2024 at 1:04 PM Robert Haas <robertmh...@gmail.com> wrote: > One caveat here, > perhaps, is that the focus of the work you've done up until now and > the things that I and other community members may want as a condition > of merging stuff may be somewhat distinct. You will have naturally > been focused on your goals rather than other people's goals, or so I > assume.
Right. That's a risk I knew I was taking when I wrote it, so it's not going to offend me when I need to rewrite things. > I would be a bit wary of splitting it up over > too many different threads. It may well make sense to split it up, but > it will probably be easier to review if the core work to enable this > is one patch set on one thread where someone can read just that one > thread and understand the situation, rather than many threads where > you have to read them all. I'll try to avoid too many threads. But right now there is indeed just one thread (OAUTHBEARER) and it's way too much: - the introduction of pytest - a Construct-based manipulation of the wire protocol, including Wireshark-style network traces on failure - pytest fixtures which spin up libpq and the server in isolation from each other, relying on the Construct implementation to complete the seam - OAuth, which was one of the motivating use cases (but not the only one) for all of the previous items I really don't want to derail this thread with those. There are other people here with their own hopes and dreams (see: unconference notes), and I want to give them a platform too. > > That doesn't mean I want to > > do this without a plan; it just means that the plan can involve saying > > "this is not working and we can undo it" which makes the uncertainty > > easier to take. > > As a community, we're really bad at this. [...] I will carry the response to this to the next email. Thanks, --Jacob
