Re: proposal: psql: show current user in prompt

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: proposal: psql: show current user in prompt
Дата
Msg-id CAFj8pRBDyjwk1-xhnAJQ4cC+G0tMq2ZozL7Pocun56U9MbvEhw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: proposal: psql: show current user in prompt  (Jelte Fennema <postgres@jeltef.nl>)
Ответы Re: proposal: psql: show current user in prompt  (Jelte Fennema <postgres@jeltef.nl>)
Список pgsql-hackers
Hi

po 8. 5. 2023 v 14:22 odesílatel Jelte Fennema <postgres@jeltef.nl> napsal:
I'm very much in favor of adding a way to support reporting other GUC
variables than the current hardcoded list. This can be quite useful to
support some amount of session state in connection poolers.

Some general feedback on the patch:
1. I don't think the synchronization mechanism that you added should
be part of PQlinkParameterStatus. It seems likely for people to want
to turn on reporting for multiple GUCs in one go. Having to
synchronize for each would introduce unnecessary round trips. Maybe
you also don't care about syncing at all at this point in time.

I don't understand how it can be possible to do it without.  I need to process possible errors, and then I need to read and synchronize protocol. I didn't inject
this feature to some oher flow, so I need to implement a complete process. For example, PQsetClientEncoding does a PQexec call, which is much more expensive. Unfortunately, for this feature, I cannot change some local state variables, but I need to change the state of the server. Own message is necessary, because we don't want to be limited by the current transaction state, and then we cannot reuse PQexec.

The API can be changed from PQlinkParameterStatus(PGconn *conn, const char *paramName)

to

PQlinkParameterStatus(PGconn *conn, int nParamNames, const char *paramNames)

What do you think?

Regards

Pavel
 

2. Support for this message should probably require a protocol
extension. There is another recent thread that discusses about adding
message types and protocol extensions:
https://www.postgresql.org/message-id/flat/CA%2BTgmoaxfJ3whOqnxTjT-%2BHDgZYbEho7dVHHsuEU2sgRw17OEQ%40mail.gmail.com#acd99fde0c037cc6cb35d565329b6e00

3. Some tests for this new libpq API should be added in
src/test/modules/libpq_pipeline

4. s/massages/messages


Finally, I think this patch should be split into two commits:
1. adding custom GUC_REPORT protocol support+libpq API
2. using this libpq API in psql for the user prompt

If you have multiple commits (which are rebased on master), you can
very easily create multiple patch files using this command:
git format-patch master --base=master --reroll-count={version_number_here}


On Fri, 28 Apr 2023 at 07:00, Pavel Stehule <pavel.stehule@gmail.com> wrote:
>
>
>
> čt 27. 4. 2023 v 7:39 odesílatel Pavel Stehule <pavel.stehule@gmail.com> napsal:
>>
>> Hi
>>
>> rebased version + fix warning possibly uninitialized variable
>
>
> fix not unique function id
>
> Regards
>
> Pavel
>
>>
>> Regards
>>
>> Pavel
>>

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Dean Rasheed
Дата:
Сообщение: Re: cataloguing NOT NULL constraints
Следующее
От: Robert Haas
Дата:
Сообщение: Re: cataloguing NOT NULL constraints