Re: Report search_path value back to the client.

On 7/20/24 14:09, Jelte Fennema-Nio wrote:
> On Fri, 19 Jul 2024 at 21:48, Tomas Vondra
> <tomas(dot)vondra(at)enterprisedb(dot)com> wrote:
>>
>>
>>
>> On 7/19/24 17:16, Jelte Fennema-Nio wrote:
>>> That's been moving forward, even relatively fast imho for the
>>> size/impact of that patchset. But those changes are much less
>>> straight-forward than this patch. And while I hope that they can get
>>> committed for PG18 this year, I'm not confident about that.
>>
>> I don't know. My experience is that whenever we decided to not do a
>> simple improvement because a more complex patch was expected to do
>> something better/smarter, we often ended up getting nothing.
>>
>> So maybe it'd be best to get this committed, and then if the other patch
>> manages to get into PG18, we can revert this change (or rather that
>> patch would do that).
>
> Yeah, I think we're aligned on this. Because that's totally what I
> meant to say, but I don't seem to have written down that conclusion
> explicitly.
>
>> Maybe it's crazy-talk, but couldn't we make the GUC settable exactly
>> once? That should be doable using the GUC hooks, I think. That means
>> pgbouncer would set the GUC right after opening the connection, and then
>> the following attempts to set it would either error out, or silently do
>> nothing?
>>
>> Perhaps it could even allow enabling reporting for more GUCs, but once a
>> GUC is on the list, it's reported forever.
>
> This could maybe work, I'll think a bit about it. The main downside I
> see is that PgBouncer can then not act as a transparent proxy, because
> it cannot reset value to the value that the client expects the GUC to
> be. But in practice that doesn't matter much for this specific case
> because all that happens in this case is that the client gets a few
> more ParameterStatus messages that it did not want.

I understand that point of view, but I don't quite share it. I don't
really see this as a GUC, even if it's implemented as one. It's just a
convenient way to enable a protocol feature without having to modify the
protocol ... It could easily be a enable_param_report() function, doing
the same thing, for example.

It's a bit of a tangent, but this reminds me how Oracle uses logon
triggers to set "application context" for their variant of RLS. In
postgres that was not possible because we did not have "logon" triggers,
but in 17 that will change. I wonder it that could be handy, but maybe
not - it seems unnecessarily complex.

regards

--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company