Re: proposal: psql: show current user in prompt

po 29. 1. 2024 v 10:26 odesílatel Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
napsal:

>
>
> ne 28. 1. 2024 v 22:52 odesílatel Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>
> napsal:
>
>> On Sun, 28 Jan 2024 at 20:01, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
>> wrote:
>> > There is another reason - compatibility with other drivers. We
>> maintain just libpq, but there are JDBC, Npgsql, and some native Python
>> drivers. I didn't checked, but maybe they expect GUC with GUC_REPORT flag.
>>
>> This doesn't matter, because these drivers themselves would only stop
>> receiving certain GUC report messages if they changed this the
>> _pq_.report_paramers GUC. And at that point the other driver is
>> disabling the reporting on purpose. But like I said, I'm fine with
>> forcing the currently default GUC_REPORT GUCs to be GUC_REPORT always
>> (maybe excluding application_name).
>>
>
> ok
>
>
>>
>> > But now, I don't see any design without problems. Your look a little
>> bit fragile to me,
>>
>> Can you explain what still looks fragile to you about my design? Like
>> I explained at least from a proxy perspective this is the least
>> fragile imho, since it can reuse already existing and battle tested
>> code.
>>
>
> because there is not 100% isolation of different layers, there is one
> resource that can be modified by network layer (proxy) and by application
> layer (psql). Unfortunately, I don't see any better solution, how these
> layes separated.
>
>
>
>>
>> > From my perspective the situation can be better if I know so defaultly
>> reported GUC are fixed, and cannot be broken. Then for almost all clients
>> (without pgbouncer users), the CUSTOM_REPORT_GUC GUC will contain just
>> "role", and then the risk is minimal.
>>
>> Which risk are you talking about here?
>>
>
> The risk of not wanted reporting. I'll return to my psql prompt case. Who
> will disable reporting of "rule", when psql crashes? pgbouncer will call
> DISCARD ALL before reuse connection, but it ignores
> _pq_.report_parameters/';.>"
>
>
>
>>
>> > But still there are problems with handling of RESET ALL - so that means
>> I need to do a recheck of the local state every time, when I will show a
>> prompt with %N - that is not nice, but probably with a short list it will
>> not be a problem.
>>
>> I'm not entirely sure what you mean here. Is this still a problem if
>> RESET ALL is ignored for _pq_.report_parameters? If so, what problem
>> are you talking about then?
>>
>> > But I can imagine a client crash, and then pgbouncer executes RESET
>> ALL, and at this moment I would like to reset GUC_REPORT on "role" GUC.
>> Maybe the introduction of a new flag for DISCARD can solve it. But again
>> there can be a problem for which GUC the flag GUC_REPORT should be removed,
>> because there are not two independent lists.
>>
>> I don't think this is a problem. PgBouncer wouldn't rely on RESET ALL
>> to reset the state of _pq_.report_parameters. Before handing off the
>> old connection to a new client, PgBouncer would simply change the
>> _pq_.report_parameters GUC back to its default value by sending a
>> ParameterSet message. i.e. PgBouncer would use the same logic as it
>> currently uses to correctly reset tracked GUCs (application_name,
>> client_encoding, etc).
>>
>
> ok, this can work, and this is the reply to my previous query.
>

I marked my patch as withdrawn. I'll resend it when your patch
_pq_.report_parameters
will be committed.

Regards

Pavel

>
> Regards
>
> Pavel
>