Re: Global/persistent variables - Mailing list pgsql-general

From Richard_D_Levine@raytheon.com
Subject Re: Global/persistent variables
Date
Msg-id OF5EFCAF7F.F2ABAC33-ON05256F81.0078A38A@ftw.us.ray.com
Whole thread Raw
In response to Global/persistent variables  (Ronnie Meier Ramos <ronnie@viler.com.br>)
List pgsql-general
I understand your pain, because PL/SQL is so close to plpgsql the functions
should just drop into quotes with renamed parameters, but they don't.
Using another language makes the port more difficult.

Have you considered functions that store the variable value in the database
and read it back from there?  The functions would have to store variables
values by some kind of session or user ID so concurrent sessions wouldn't
trump one another.  This would help with variable reference but variable
assignment would require more recoding.

There is also the issue of initializing sessions and cleaning up after
them.  Not pretty.

Rick



                     
                      Tom Lane
                     
                      <tgl@sss.pgh.pa.us>            To:       Ronnie Meier Ramos <ronnie@viler.com.br>
                     
                      Sent by:                       cc:       pgsql-general@postgresql.org
                     
                      pgsql-general-owner@pos        Subject:  Re: [GENERAL] Global/persistent variables
                     
                      tgresql.org
                     

                     

                     
                      01/06/2005 03:43 PM
                     

                     

                     




Ronnie Meier Ramos <ronnie@viler.com.br> writes:
> AFAIK PG doesn't have packages - this is not a problem since I can
> handle it with different schemas or some naming convention, but is there
> a way to declare persistent variables (that would be "visible" to any
> function up to the end of the session) ?

plpgsql doesn't have this at present, but some of the other PLs do.

                                     regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
      joining column's datatypes do not match




pgsql-general by date:

Previous
From: Scott Ribe
Date:
Subject: Re: Global/persistent variables
Next
From: Bruno Wolff III
Date:
Subject: Re: postgresql-contrib risks?