Re: [9.0] On temporary tables

2010/9/30 Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>:
> 2010/9/30 Vincenzo Romano <vincenzo(dot)romano(at)notorand(dot)it>:
>> 2010/9/30 Pavel Stehule <pavel(dot)stehule(at)gmail(dot)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.

--
Vincenzo Romano at NotOrAnd Information Technologies
Software Hardware Networking Training Support Security
--
NON QVIETIS MARIBVS NAVTA PERITVS