> We'd be interested in a stripped down libpq as well; a couple of our embedded Linux platforms built in Buildroot include PostgreSQL, and it accounts for roughly 15% and 20% of our firmware bundles respectively - one of the taller nails in the BSPs. Both of these platforms are only ever clients!
If this feature doesn't move forward in postgres, if you're interested, would love the help syncing our stripped down fork with upstream. > I'm also not particularly keen on adding a dependency on autoconf/make This is true for us too. We're trying to reduce all reliance on autoconf. -- Benjamin W. Leff On Thu, Jan 15, 2026 at 12:29 PM Jaroslaw Ciba <[email protected]> wrote: > Hey all, > > Just thought I would bump this thread given Benjamin has been the only one > to request the feature thus far. It was nice to bump into this thread when > I was evaluating client-side builds in December myself. > > We'd be interested in a stripped down libpq as well; a couple of our > embedded Linux platforms built in Buildroot include PostgreSQL, and it > accounts for roughly 15% and 20% of our firmware bundles respectively - one > of the taller nails in the BSPs. Both of these platforms are only ever > clients! > > With autoconf it is trivial to get a client-side version only - just 4 > make commands do the trick. As part of upgrading BSPs I considered adding > an internal Buildroot package relying on this, given it's a good > opportunity to go through smoke testing and see it not break anything, but > I currently do not want to increase the maintenance burden in moving BSPs > forward. I'm also not particularly keen on adding a dependency on > autoconf/make given it's only been said it won't be dropped in the near > future - I don't particularly want some developer here in 5 years' time to > have to tear their hair out! Having this problem solved externally would be > great, though I more than understand the need to balance resources. > > Best, > Jaroslaw Ciba > [image: ltp|17685019294754567]
