Hi,
On 2022-06-16 12:04:12 -0400, Greg Stark wrote:
> Of course this patch is still very WIP. Only one or the other function
> makes sense to keep. And I'm not opposed to having a GUC to
> enable/disable the enforcement or warnings. And the code itself needs
> to be cleaned up with parts of it
On Thu, 16 Jun 2022 at 12:04, Greg Stark wrote:
>
> Providing a fixed up search_path for users would give them a smoother
> upgrade process where we can give a warning only if the search_path is
> changed substantively which is much less likely.
>
> I'm still quite concerned about the performance
On Mon, 13 Jun 2022 at 16:50, Greg Stark wrote:
>
> For that matter the gotchas are a bit convoluted
>
> Perhaps we should automatically fix up the current search patch and
> attach it to functions where necessary for users instead of just
> whingeing at them
So I reviewed my
On Mon, Jun 13, 2022 at 06:41:17PM -0700, Peter Geoghegan wrote:
> On Mon, Jun 13, 2022 at 1:51 PM Greg Stark wrote:
>> By "relatively common" I think we're talking "nigh universal". Afaics
>> there are no warnings in the docs about worrying about search_path on
>> IMMUTABLE functions. There is
On Mon, Jun 13, 2022 at 1:51 PM Greg Stark wrote:
> By "relatively common" I think we're talking "nigh universal". Afaics
> there are no warnings in the docs about worrying about search_path on
> IMMUTABLE functions. There is for SECURITY DEFINER but I have to admit
> I wasn't aware myself of all
On Thu, 9 Jun 2022 at 16:12, Peter Geoghegan wrote:
>
> Presumably there is still significant value in detecting cases where
> some user-defined code provably does the wrong thing. Especially by
> targeting mistakes that experience has shown are relatively common.
> That's what the search_path
On Thu, Jun 9, 2022 at 12:39 PM Greg Stark wrote:
> Generally I think the idea is that the user *is* responsible for
> writing immutable functions carefully to hide any non-deterministic
> behaviour from the code they're calling. But that does raise the
> question of why to focus on search_path.
On Wed, 8 Jun 2022 at 19:39, Mark Dilger wrote:
>
>
> I like the general idea, but I'm confused why you are limiting the analysis
> to search path resolution. The following is clearly wrong, but not for that
> reason:
>
> create function public.identity () returns double precision as $$
>
> On Jun 8, 2022, at 2:42 PM, Greg Stark wrote:
>
> Thinking of plpgsql here, we already run the raw parser on all sql
> when the function is defined. We could somehow check whether the
> raw_parser found any non-schema-qualified references. This looks like
> it would be awkward but doable.
Recently I had someone complaining about a pg_restore failure and I
believe we semi-regularly get complaints that are similar -- though
I'm having trouble searching for them because the keywords "dump
restore failure" are pretty generic.
The root cause here -- and I believe for a lot of users --
10 matches
Mail list logo
