2010/9/30 Vincenzo Romano <vincenzo.romano@xxxxxxxxxxx>: > 2010/9/30 Pavel Stehule <pavel.stehule@xxxxxxxxx>: >> 2010/9/30 Vincenzo Romano <vincenzo.romano@xxxxxxxxxxx>: >>> 2010/9/30 Pavel Stehule <pavel.stehule@xxxxxxxxx>: >>>> 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 > -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
