| From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
|---|---|
| To: | Joel Jacobson <joel(at)compiler(dot)org> |
| Cc: | Isaac Morland <isaac(dot)morland(at)gmail(dot)com>, Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>, Marko Tiikkaja <marko(at)joh(dot)to>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Chapman Flack <chap(at)anastigmatix(dot)net> |
| Subject: | Re: security_definer_search_path GUC |
| Date: | 2021-06-04 06:58:15 |
| Message-ID: | CAFj8pRCzzmWdRivSK88eNe2fsx-HHChuz_v96bax=uje+vnM0Q@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi
>
> I realise "eliminate" is not really necessary, it would suffice to just
> allow setting a a sane default per database, and make that value immutable,
> then all data structures and code using wouldn't need to change, one would
> then only need to change the code that can mutate search_path, to prevent
> that from happening.
>
I understand that for some specific cases the search_path can be
problematic. On the other hand, the SQL database supports interactive work,
and then the search_path can save a lot of monkey work.
It is the same as using the command line without the possibility to
customize the PATH variable. The advantages and disadvantages are exactly
the same.
Regards
Pavel
| From | Date | Subject | |
|---|---|---|---|
| Next Message | ikedamsh@oss.nttdata.com | 2021-06-04 06:58:47 | Re: Transactions involving multiple postgres foreign servers, take 2 |
| Previous Message | Heikki Linnakangas | 2021-06-04 06:42:22 | Re: Make unlogged table resets detectable |