Re: Does a call to a language handler provide a context/session, and somewhere to keep session data? - Mailing list pgsql-general

From Jan de Visser
Subject Re: Does a call to a language handler provide a context/session, and somewhere to keep session data?
Date
Msg-id 2773154.9cXRjvk1m4@coyote
Whole thread Raw
In response to Re: Does a call to a language handler provide a context/session, and somewhere to keep session data?  (<david@andl.org>)
Responses Re: Does a call to a language handler provide a context/session, and somewhere to keep session data?  (<david@andl.org>)
List 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 by date:

Previous
From:
Date:
Subject: Re: Does a call to a language handler provide a context/session, and somewhere to keep session data?
Next
From: Craig Ringer
Date:
Subject: Re: Slave-Master replication on top of BDR