Re: pgsql: Fix search_path to a safe value during maintenance operations.

On Tue, 2023-08-01 at 13:41 -0400, Robert Haas wrote:
> In functions and procedures, except for the new
> BEGIN ATOMIC stuff, we just store the statements as a string and they
> get parsed at execution time.

...

> I think that a lot of people would like it if we moved more in the
> direction of parsing statements at object definition time.

Do you mean that we'd introduce some BEGIN ATOMIC version of plpgsql
(and other trusted languages)?

> However, there are some
> fairly significant problems with that idea.

To satisfy intended use cases of things like default expressions, CHECK
constraints, index expressions, etc., there is no need to call
functions that would be subject to the problems you list.

One problem is that functions are too general a concept -- we have no
idea whether the user is trying to do something simple or trying to do
something "interesting".

> Now, if we don't go in the direction of resolving everything at parse
> time,

It would be useful to pursue this approach, but I don't think it will
be enough. We still need to solve our search_path problems.

> then I think capturing search_path is probably the next best
> thing,

+0.5.

> To be honest, I think it's
> a
> bit of a kludge, and dropping a kludge on top of our entire user base
> and maybe also breaking a lot of things is not particularly where I
> want to be. I just don't have an idea I like better at the moment.

We will also be fixing things for a lot of users who just haven't run
into a problem *yet* (or perhaps did, and just don't know it).

Regards,
Jeff Davis