Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs
Дата
Msg-id 376846.1716489602@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs  (Jacob Champion <jacob.champion@enterprisedb.com>)
Ответы Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs
Список pgsql-hackers
Jacob Champion <jacob.champion@enterprisedb.com> writes:
> Would it be good to expand on that idea of criticality? IIRC one of
> Jelte's complaints earlier was that middleware has to know all the
> extension types anyway, to be able to figure out whether it has to do
> something about them or not. HTTP has the concept of hop-by-hop vs
> end-to-end headers for related reasons.

Yeah, perhaps.  We'd need to figure out just which classes we need
to divide protocol parameters into, and then think about a way for
code to understand which class a parameter falls into even when
it doesn't specifically know that parameter.  That seems possible
though.  PNG did it with spelling rules for the chunk labels.
Here, since we don't yet have any existing _pq_.xxx parameter names,
we could maybe say that the names shall follow a pattern like
"_pq_.class.param".  (That works only if the classes are
non-overlapping, an assumption not yet justified by evidence;
but we could do something more complicated if we have to.)

            regards, tom lane



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

Предыдущее
От: Jacob Champion
Дата:
Сообщение: Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs