On Thu, Sep 13, 2018 at 1:51 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Thomas Munro <thomas.munro@enterprisedb.com> writes:
> > ... Do we really want to crack down on
> > extension libraries that wouldn't work in shared_preload_libraries?
>
> That is, perhaps, a fair question; but I see little benefit to users
> in such a library design. Most people who are using a library heavily
> would likely wish to have it preloaded.
>
> > What about hypothetical libraries that are smart enough to avoid
> > making such calls when they detect that they're running from
> > shared_preload_libraries -- you'd generate false warnings when loaded
> > the regular way.
>
> I find that argument too thin to take seriously. If the library
> can manage that, it might as well just postpone the calls all the
> time, rather than have two different operating modes that would
> require separate testing. What would be the advantage of the
> extra complication?
Ok, 0003 (attached) is a straw-man patch to log a warning. I guess it
won't be too popular with anyone who has worked on making syscache as
fast as possible.
postgres=# select unaccent('hello');
WARNING: syscache access from _PG_init() is deprecated and will not
be allowed in a future release of PostgreSQL
unaccent
----------
hello
(1 row)
You see this warning only once per library per backend (including
parallel workers, as can be tested with the same trivial query with
force_parallel_mode = on, assuming 0002 is also applied so it doesn't
crash).
--
Thomas Munro
http://www.enterprisedb.com
