On Wed, 2024-02-28 at 10:55 -0600, Nathan Bossart wrote:
> I'm afraid I don't have a better idea than adding a short note in
> each
> affected commands's page.
OK, that works for now.
Later we should also document that the functions are run as the table
owner.
> > On Fri, 2024-02-23 at 15:30 -0600, Nathan Bossart wrote:
> > > I wonder if it's worth using PGC_S_INTERACTIVE or introducing a
> > > new
> > > value
> > > for these.
> >
> > Did you have a particular concern about PGC_S_SESSION?
>
> My only concern is that it could obscure the source of the
> search_path
> change, which in turn might cause confusion when things fail.
That's a good point. AutoVacWorkerMain uses PGC_S_OVERRIDE, but it
doesn't have to worry about SET, because there's no real session.
The function SET clause uses PGC_S_SESSION. It's arguable whether
that's really the same source as a SET command, but it's definitely
closer.
>
> Yeah, we would have to make it equivalent in priority to
> PGC_S_SESSION,
> which would likely require a bunch of special logic.
I'm not clear on what problem that would solve.
> I don't doubt anything you've said, but I can't help but think that
> we
> might as well handle the pg_temp risk, too.
That sounds good to me, but I didn't get many replies in that last
thread. And although it solves the problem, it is a bit awkward.
Can we get some closure on whether that !pg_temp patch is the right
approach? That was just my first idea, and it would be good to hear
what others think.
> Furthermore, I see that we use "" as a safe search_path for
> autovacuum and
> fe_utils/connect.h. Is there any way to unite these?
We could have a single function like RestrictSearchPath(), which I
believe I had in some previous iteration. That would use the safest
search path (either excluding pg_temp or putting it at the end) and
PGC_S_SESSION, and then use it everywhere.
Regards,
Jeff Davis