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

From
Subject Re: Does a call to a language handler provide a context/session, and somewhere to keep session data?
Date
Msg-id 000a01d17873$cd09d1c0$671d7540$@andl.org
Whole thread Raw
In response to Re: Does a call to a language handler provide a context/session, and somewhere to keep session data?  (John R Pierce <pierce@hogranch.com>)
Responses Re: Does a call to a language handler provide a context/session, and somewhere to keep session data?  (Jan de Visser <jan@de-visser.net>)
List pgsql-general

From: pgsql-general-owner@postgresql.org [mailto:pgsql-general-owner@postgresql.org] On Behalf Of John R Pierce

Yes, I was aware of GD and SD. My question is about what facilities Postgres provides for implementing such a thing. Where is the proper place for the root of the SD/GD? What does an implementation use to determine that two calls belong to the same session?

the process ID is unique for each active session.   of course, the OS can recycle a PID when a process/connection terminates

[dmb>] Thanks for the idea, but I’m wary of using PID for that purpose.

[dmb>] In the Python implementation the GD appears to just be stored as a simple variable at file scope in the DLL. Would I be right in saying that the language handler DLL is loaded exactly once for each session (when the language is first used)? If so, then any unique identifier allocated in PG_init (such as a GUID or timestamp or counter) would seem to serve the purpose. I just wondered if there was something clever I hadn’t found out about yet.

 

Regards

David M Bennett FACS


Andl - A New Database Language - andl.org

 

pgsql-general by date:

Previous
From: Geoff Winkless
Date:
Subject: Re: index problems (again)
Next
From: Victor Yegorov
Date:
Subject: Re: index problems (again)