Re: Does a call to a language handler provide a context/session, and somewhere to keep session data?
От | Jan de Visser |
---|---|
Тема | Re: Does a call to a language handler provide a context/session, and somewhere to keep session data? |
Дата | |
Msg-id | 2773154.9cXRjvk1m4@coyote обсуждение исходный текст |
Ответ на | Re: Does a call to a language handler provide a context/session, and somewhere to keep session data? (<david@andl.org>) |
Ответы |
Re: Does a call to a language handler provide a context/session, and somewhere to keep session data?
|
Список | pgsql-general |
On March 8, 2016 11:35:00 AM david@andl.org wrote: > From: pgsql-general-owner@postgresql.org > [mailto:pgsql-general-owner@postgresql.org] On Behalf Of John R Pierce > > this stuff you're loading from the database once, that's just data about > your language plugin's configuration, or is it user data, or what? [dmb>] > It's the catalog for Andl. It contains defined functions, types, persistent > scalar (non table) data values and links to tables. > > if its just a few global settings, you should consider using custom > settings variables, rather than database tables. for instance, pljava has > a setting, pljava.libjvm_location='/usr/lib/jvm/java-1.8.0/lib/libjvm.so' > or whatever which it uses to find the Java native calls interface > library... [dmb>] Andl has something similar, but that problem is already > solved. You're being pretty oblique about what it is you're trying to achieve. To go back to one of your earlier emails: the hardest problem in computing isn't cache invalidation. It is clearly explaining what the problem at hand is.
В списке pgsql-general по дате отправления: