2010/9/30 Vincenzo Romano <vincenzo.romano@notorand.it>:
> 2010/9/30 Pavel Stehule <pavel.stehule@gmail.com>:
>> 2010/9/30 Vincenzo Romano <vincenzo.romano@notorand.it>:
>>> 2010/9/30 Pavel Stehule <pavel.stehule@gmail.com>:
>>>> Hello
>>>>>> but if you need a session variables, then you can use a plperl
>>>>>>
>>>>>> http://www.postgresql.org/docs/9.0/static/plperl-global.html
>>>>>
>>>>> I will look into this. What I need is a set of variable for each connection.
>>>>>
>>>>
>>>> understand - attention - session variables are nice but problematic
>>>> when you use some form of connection pooling
>>>
>>> I do know I'll need to be careful, even without connection pooling.
>>> What'd be a different solution to implement session variables?
>>> Just PLPERL?
>>
>> plperl or C or custom guc .. the using plperl is probably most simple and fast
>>
>> Pavel
>>
>> http://www.pgsql.cz/index.php/PostgreSQL_SQL_Tricks#Any_other_session_variables
>>
>> I don't know what do you do - but some times better is don't use a
>> session variables on server - just use a application variables
>> together with stored procedures. What I remember my last bigger
>> project, we did a some problems with session variables from PHP, where
>> PHP sessions sometimes recycled a db session, so probably better to
>> don't use it.
>>
>> Pavel
>
> A few of those session variables are needed by functions and views to
> change their output (and behavior).
> For example, one session variable is the "reference" time I use to
> select into history tables.
> A user can be using a reference time in the future (to see how
> projectons are), while another one is using
> the current_timestamp to work on current data.
> I don't see any better way than temp tables. So far.
>
we did same design - it works well from single client application and
not too much well from some application servers. Our solution was to
use a special parameter for every function - like some session handle
- and without session depending views we used a parametrized SRF
functions with handle parameter.
But this project was started about 2005, so now a situation can be different.
Regards
Pavel
> --
> Vincenzo Romano at NotOrAnd Information Technologies
> Software Hardware Networking Training Support Security
> --
> NON QVIETIS MARIBVS NAVTA PERITVS
>