Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Jun 12, 2024 at 6:43 PM Jelte Fennema-Nio <postgres@jeltef.nl> wrote:
>> I agree it's not a technical issue. It is a people issue. There are
>> very few people skilled in Perl active in the community. And most of
>> those are very senior hackers that have much more important things to
>> do that make our Perl testing framework significantly better. And the
>> less senior people that might see improving tooling as a way to get
>> help out in the community, are try to stay away from Perl with a 10
>> foot pole. So the result is, nothing gets improved. Especially since
>> very few people outside our community improve this tooling either.
> I agree with you, but I'm skeptical that solving it will be as easy as
> switching to Python. For whatever reason, it seems like every piece of
> infrastructure that the PostgreSQL community has suffers from severe
> neglect.
Yeah. In this case it's perhaps more useful to look at our external
dependencies, the large majority of which are suffering from age
and neglect:
* autoconf & gmake (although meson may get us out from under these)
* bison
* flex
* perl
* tcl
* regex library (basically from tcl)
* libxml2
* kerberos
* ldap
* pam
* uuid library
I think the basic problem is inherent in being a successful long-lived
project. Or maybe we're just spectacularly bad at picking which
things to depend on. Whichever it is, we'd better have a 10- or 20-
year perspective when thinking about adopting new major dependencies.
In the case at hand, I share Robert's doubts about Python. Sure it's
more popular than Perl, but I don't think it's actually better, and
in some ways it's worse. (The moving-target package collection was
mentioned as a problem, for instance.) Is it going to age better
than Perl? Doubt it.
I wonder if we should be checking out some of the other newer
languages that were mentioned upthread. It feels like going to
Python here will lead to having two testing infrastructures with
mas-o-menos the same capabilities, leaving us with a situation
where people have to know both languages in order to make sense of
our test suite. I find it hard to picture that as an improvement
over the status quo.
regards, tom lane
