Re: Make stream_prepare an optional callback

From: Markus Wanner <markus(at)bluegap(dot)ch>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Markus Wanner <markus(dot)wanner(at)enterprisedb(dot)com>
Cc: Ajin Cherian <itsajin(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Make stream_prepare an optional callback
Date: 2021-03-09 08:53:44
Message-ID: c8a0b628-f2d0-6224-b0f0-ef56f065bc74@bluegap.ch
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 09.03.21 09:39, Amit Kapila wrote:
> It is attached with the initial email.

Oh, sorry, I looked up the initial email, but still didn't see the patch.

> I think so. The behavior has to be similar to other optional callbacks
> like message_cb, truncate_cb, stream_truncate_cb. Basically, we don't
> need to error out if those callbacks are not provided.

Right, but the patch proposes to error out. I wonder whether that could
be avoided.

> The extension can request two_phase without streaming.

Sure. I'm worried about the case both are requested, but filter_prepare
returns false, i.e. asking for a streamed prepare without providing the
corresponding callback.

I wonder whether Postgres could deny the stream_prepare right away and
not even invoke filter_prepare. And instead just skip it because the
output plugin did not provide an appropriate callback.

An error is not as nice, but I'm okay with that as well.

Best Regards

Markus

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Khandekar 2021-03-09 09:00:21 Re: [POC] verifying UTF-8 using SIMD instructions
Previous Message Fujii Masao 2021-03-09 08:51:29 Re: About to add WAL write/fsync statistics to pg_stat_wal view