Tom Lane wrote: > Richard Huxton <dev@xxxxxxxxxxxx> writes: > >>One thing I think would be useful is another pseudo-var in PG, >>something like APP_SESSION_VAR which can be set and then used in PG >>queries. > > >>Tom - if I offered to produce a patch for something like this - either a var >>or a function pair (get_app_session_var(), set_app_session_var(varchar)) >>would it be likely to be accepted? > > > It'd depend a lot on the details of what you propose, I think. True > variables seem like they'd be rather invasive, not to mention possibly > error-prone (is "foo" a variable or a column reference?). However you > could do something pretty self-contained in the form of a couple of > functions. I'd suggest they support more than just one variable, btw. > How about "set_session_variable(varname, varvalue)" and > "get_session_variable(varname)"? > > I should think we'd at least accept that as a contrib module; whether it > would become mainstream would probably depend on the level of interest. In the past, one hack would be to use setenv() and getenv() of the backend to implement these functions. What about a contrib module that: 1) At set_session_variable(), a getenv() on the key (PG_APP_SESSION_VAR) is made to see if memory has already been allocated for a private variable map. If so, add the variable to the map, else allocate a new map and set it's address using setenv(). 2) At get_session_variable() a getenv() on the key (PG_APP_SESSION_VAR) is made to see if a map exists. If so, it looks into the map for the value of the name specified and returns it. 3) At get reset_session_variables() a getenv() on the key (PG_APP_SESSION_VAR) is made to see if a map exists. If so, it is emptied. This way, no change to any internal postgres code is required, the memory allocated to the session-specific variables gets released at backend closing, etc. Would something like that be acceptable? Mike Mascari mascarm@xxxxxxxxxxx
