| From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
|---|---|
| To: | Nathan Bossart <nathandbossart(at)gmail(dot)com>, Greg Stark <stark(at)mit(dot)edu> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Fix search_path for all maintenance commands |
| Date: | 2023-06-09 21:00:31 |
| Message-ID: | bd46ea3bd255d4683dddef44ed28743af87862d9.camel@j-davis.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, 2023-06-08 at 21:55 -0700, Nathan Bossart wrote:
> On Thu, Jun 08, 2023 at 06:08:08PM -0400, Greg Stark wrote:
> > I guess that's pretty narrow and a reasonable thing to desupport.
> > Users could just mark those functions with search_path or schema
> > qualify the object references in them. Perhaps we should also be
> > picking up cases like that sooner so users realize they've created
> > a
> > footgun for themselves?
Many cases will be picked up, for instance CREATE INDEX will error if
the safe search path is not good enough.
> I'm inclined to agree that this is reasonable to desupport.
Committed.
> I bet we could skip forcing the search_path for maintenance commands
> run as
> the table owner, but such a discrepancy seems likely to cause far
> more
> confusion than anything else.
Agreed.
Regards,
Jeff Davis
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Gregory Smith | 2023-06-09 21:19:47 | Re: index prefetching |
| Previous Message | Jeff Davis | 2023-06-09 20:54:09 | pgsql: Fix search_path to a safe value during maintenance operations. |