I'm not exactly sure what the history behind this, but Debian and Ubuntu currently wraps around some of the PostgreSQL utilities with something called pg_wrapper. This utility uses LD_PRELOAD to instruct the linker to linker against libreadline. So there are two libraries here that are similar:
libreadlinea GPLed versionlibedita BSD-licensed version
It seems like libedit uses ABI that libreadline does and essentially reimplements the functionality of libreadline under a different more permissive license. This seems permissible to me, but regardless let's assume it is.
That said, it is my suspicion that using LD_PRELOAD to circumvent the license on indefensible. Debian relinks the runtime that was built against libedit with libreadline.
The GPL FAQ says,
Linking a GPL covered work statically or dynamically with other modules is making a combined work based on the GPL covered work. Thus, the terms and conditions of the GNU General Public License cover the whole combination. See also What legal issues come up if I use GPL-incompatible libraries with GPL software?
It's also very clear Debian's goal is to circumvent the license in that, additionally acknowledging that libedit is "broke",
pg_wrapper: If libreadline is installed, LD_PRELOAD this for "psql", to avoid using the rather brokenlibedit. We need to build thepostgresql-X.Ypackages againstlibeditfor license reasons (#603599), but aslibreadlinehas a drop-in compatible ABI, this works around the licensing restrictions. Thanks to Andreas Barth for working this out! Add a recommends to libreadline6. (Closes: #608442, #607907, #607109, #611918)
Is there any precedence for this? Is a non-GPLed program that is dependent on an ABI implemented in by two distinct libraries one of which is GPLed free to utilize the GPL'ed library because it's not a derivative work of the GPL'ed library, but only an ABI that is shared in common with two libraries?
And more simply, can you use GPLed code and not yourself be a derivative work?
You can read more about LD_PRELOAD here.