2017-11-02 13:35 GMT+01:00 Robert Haas <robertmh...@gmail.com>: > On Thu, Oct 26, 2017 at 12:51 PM, Pavel Stehule <pavel.steh...@gmail.com> > wrote: > > The variables can be modified by SQL command SET (this is taken from > > standard, and it natural) > > > > SET varname = expression; > > Overloading SET to handle both variables and GUCs seems likely to > create problems, possibly including security problems. For example, > maybe a security-definer function could leave behind variables to > trick the calling code into failing to set GUCs that it intended to > set. Or maybe creating a variable at the wrong time will just break > things randomly. >
The syntax CREATE OR REPLACE FUNCTION xxx $$ ... $$ SET GUC=, ... is always related only to GUC. So there should not be any security risk. It is another reason why GUC and variables should be separated. I know so there is risk of possibility of collision. There are two possibilities a) use different keyword - but it is out of SQL/PSM and out of another databases. b) detect possible collision and raise error when assignment is ambiguous. I am thinking about similar solution used in plpgsql, where is a possibility of collision between SQL identifier and plpgsql variable. Regards Pavel > > -- > Robert Haas > EnterpriseDB: http://www.enterprisedb.com > The Enterprise PostgreSQL Company >
