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: | Raw Message | Whole Thread | 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. |