Re: [9.0] On temporary tables

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Vincenzo Romano <vincenzo(dot)romano(at)notorand(dot)it>
Cc: PostgreSQL General <pgsql-general(at)postgresql(dot)org>
Subject: Re: [9.0] On temporary tables
Date: 2010-09-30 14:53:59
Message-ID: AANLkTinJbBMCi8YUs5NCiGqvFnKXQU4gSnNrbq86FyTV@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

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

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
>

In response to

Browse pgsql-general by date

  From Date Subject
Next Message GOO Creations 2010-09-30 15:26:02 libpq (C++) - Insert binary data
Previous Message Thom Brown 2010-09-30 14:46:14 Re: Prepared statements and unknown types