From: | Jelte Fennema-Nio <postgres(at)jeltef(dot)nl> |
---|---|
To: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
Cc: | Tatsuo Ishii <ishii(at)postgresql(dot)org>, peter(at)eisentraut(dot)org, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: protocol-level wait-for-LSN |
Date: | 2024-10-30 14:01:27 |
Message-ID: | CAGECzQRhRaOq4h-EC8YHgbiErBq5ries4Cii=hwhaM2tY_SDeQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, 30 Oct 2024 at 12:53, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
> We might have made a mistake by calling this mechanism "protocol
> extensions", because it makes people think of user-defined extensions.
I think this is a real problem, that's probably worth fixing. I
created a separate thread to address this[1]
> So yes, each protocol extension needs to know about all the other
> protocol extensions that it can be used with. In practice we'll avoid
> doing crazy stuff so that the protocol extensions are orthogonal
Just as an example, let's say we add a server-side query time to the
protocol (which honestly seems like a pretty useful feature). So that
ReadyForQuery now returns the query time if the query_time protocol.
For clients it isn't difficult at all to support any combination of
query_time & wait_for_lsn options. As long as we define that the
wait_for_lsn field is before the query_time field if both exist, then
two simple if statements like this would do the trick:
if (wait_for_lsn_enabled) {
// interpret next field as LSN
}
if (query_time_enabled) {
// interpret next field as query time
}
From | Date | Subject | |
---|---|---|---|
Next Message | Junwang Zhao | 2024-10-30 14:17:18 | Re: general purpose array_sort |
Previous Message | Jelte Fennema-Nio | 2024-10-30 13:58:44 | Use "protocol options" name instead of "protocol extensions" everywhere |