postgresql-client-common pulling in libipc-run-perl

Last week I started digging into docker image sizes, and I noticed that
perl and llvm together make up 44% of the package. My initial email
asked about a "slim" package which might change build flags.

I had thought that the dependencies on llvm and perl were coming from
the postgres server. After some further checking, I realized today that
the postgres server is pulling in llvm, but in fact it's the postgres
client that's pulling in perl. Debian packaging already splits out
plperl into a separate package with a dependency on perl, and the
postgres server package itself does not depend on perl.

Per my previous email, dpkg Installed-Size (without plperl installed):
 libperl5.36   28862 KB
 perl-modules-5.36     17816 KB
 perl  669 KB
 libio-pty-perl        103 KB
 libipc-run-perl       267 KB

Here is a dependency tree, showing how the perl packages are getting
pulled into the docker image:

perl-modules-5.36
├── libperl5.36
└───└── perl
        └── libio-pty-perl
            └── libipc-run-perl
                └── postgresql-client-common
                    ├── postgresql-common
                    │   └── postgresql-17
                    └── postgresql-client-17
                        └── postgresql-17

So the real question is why the client-common package has a hard
requirement on libipc-run-perl, and whether we can make this dependency
optional (or remove it). That would trim about 45MB off the base
container size, which is meaningful since these base images are very
widely used.

For LLVM, after giving it a little more thought, I think the best
solution would actually be to discuss on hackers the idea of making JIT
something more like an extension which can be installed separately
without a recompile, so that it could be split into a separate debian
package - similar to plperl, plpython and pltcl.

-Jeremy