Mike Mascari wrote:
> Tom Lane wrote:
>>Uh, what exactly does it buy you to involve an environment variable
>>in this process? I think it just adds fragility. (For example,
>>exposing setenv to the user creates the risk that he'll overwrite
>>something of importance, like PATH.)
>
> Actually,
Mike Mascari <[EMAIL PROTECTED]> writes:
> Actually, I meant that setenv() and getenv() would only be used to
> store the memory address of a privately manipulated variable map. I
> did not mean that it should actually be used to store and retrieve the
> variables themselves. If there is already a
Tom Lane wrote:
> Mike Mascari <[EMAIL PROTECTED]> writes:
>
>>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:
>
>
> Uh, what exactly does it buy you to involve an environment variable
> in this process
Mike Mascari <[EMAIL PROTECTED]> writes:
> 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:
Uh, what exactly does it buy you to involve an environment variable
in this process? I think it just adds fragili
Tom Lane wrote:
> Richard Huxton <[EMAIL PROTECTED]> 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
>>
