* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Stephen Frost <sfrost@snowman.net> writes:
> > * Andres Freund (andres@anarazel.de) wrote:
> >> Hm. That issue doesn't particularly concern me. Having all .so's
> >> available in the installation seems like a pretty basic
> >> requirement. Security labels are by far not the only things that'll fail
> >> without an extension's .so present, no?
>
> > It's certainly an issue that postgis users are familiar with.
>
> Really? What aspect of postgis requires mucking with
> shared_preload_libraries?
Having to have the libraries in place is what I was getting at, which is
what Andres was also talking about, if I understood correctly.
Even without having to muck with shared_preload_libraries though, you
had better have those libraries in place if you want things to work.
Having to also deal with shared_preload_libraries for some cases doesn't
strike me as a huge issue.
> If you ask me, shared_preload_libraries was only ever meant as a
> performance optimization. If user-visible DDL behavior depends on a
> library being preloaded that way, that feature is broken. There
> are some cases where we probably don't care enough to provide a
> proper solution, but I'm not sure why we would think that security
> labels fall in the don't-really-give-a-damn-if-it-works class.
I agree that labels are important and that we really want the label
provider loaded from shared_preload_libraries. I also understand that
shared_preload_libraries was originally intended as a performance
optimization and that the security labels system has ended up changing
that. I don't believe that'll be the last thing which we want to be
loaded and running from the very start (if we end up with auditing as an
extension, or any hooks in the postmaster that we provide for extensions
to use, etc).
Thanks,
Stephen