| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: proposal: schema variables |
| Date: | 2017-11-02 12:35:54 |
| Message-ID: | CA+TgmoaZ0iymUS_ZM6LW2yWjabwQs4K8=4GYR1+u-V7ROPz0nA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-performance |
On Thu, Oct 26, 2017 at 12:51 PM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2017-11-02 12:49:47 | Re: pgsql: Fix freezing of a dead HOT-updated tuple |
| Previous Message | Ildus Kurbangaliev | 2017-11-02 12:28:36 | Re: Custom compression methods |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Craig Ringer | 2017-11-02 15:07:55 | Re: proposal: schema variables |
| Previous Message | Laurenz Albe | 2017-11-02 08:30:28 | Re: OLAP/reporting queries fall into nested loops over seq scans or other horrible planner choices |