On Thu, Jun 13, 2024 at 1:04 PM Robert Haas <robertmhaas@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
