Re: security_definer_search_path GUC

čt 3. 6. 2021 v 8:14 odesílatel Joel Jacobson <joel(at)compiler(dot)org> napsal:

> On Thu, Jun 3, 2021, at 00:55, Marko Tiikkaja wrote:
>
> On Wed, Jun 2, 2021 at 11:32 PM Joel Jacobson <joel(at)compiler(dot)org> wrote:
>
> But if running a recent PostgreSQL version, with support for extensions, I
> think an even cleaner solution
> would be to package such compatibility versions in a "compat" extension,
> that would just install them into the public schema.
>
>
> Writing, verifying and shipping extension upgrade scripts is not pleasant.
>
>
> I agree. Thanks for acknowledging this problem.
>
> I'm experimenting with an idea that I hope can simplify the "verifying"
> part of the problem.
> hope to have something to show you all soon.
>
> I'd much prefer something that's integrated to the workflow I already have.
>
>
> Fair point. I guess also the initial switching cost of changing workflow
> is quite high and difficult to motivate. So even if extensions ergonomics
> are improved, many existing users will not migrate their workflows anyway
> due to this.
>
>
>
> And if you wonder what functions in public come from the compat extension,
> you can use use \dx+.
>
>
> They still show up everywhere when looking at "public". So this is only
> slightly better, and a maintenance burden.
>
>
> Good point. I find this annoying as well sometimes.
>
> It's easy to get a list of all objects for an extension, via \dx+
>
> But it's hard to see what objects in a schema, that are provided by
> different extensions, via e.g. \df public.*
>
> What about adding a new "Extension" column next to "Schema" to the
> relevant commands, such as \df?
>

I think so for \df+ it can be very useful. I don't think it is important
enough to be in short form, but it can be nice in enhanced form.

Pavel

> /Joel
>