Re: Does a call to a language handler provide a context/session, and somewhere to keep session data?
От | |
---|---|
Тема | Re: Does a call to a language handler provide a context/session, and somewhere to keep session data? |
Дата | |
Msg-id | 000a01d17873$cd09d1c0$671d7540$@andl.org обсуждение исходный текст |
Ответ на | Re: Does a call to a language handler provide a context/session, and somewhere to keep session data? (John R Pierce <pierce@hogranch.com>) |
Ответы |
Re: Does a call to a language handler provide a context/session, and somewhere to keep session data?
|
Список | 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 по дате отправления: