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. -- 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
