Skip to content

Conversation

@heavycrystal
Copy link
Contributor

This version of the protocol allows subscribers to act on prepared transactions. Previously, the prepare part of prepared transactions was not visible to subscribers and they acted like committed/rolled back (only visible if streamed) transactions.

This protocol version adds new message types and doesn't change existing ones.

Tests added.

@jackc
Copy link
Owner

jackc commented Mar 15, 2025

It seems reasonable to me, but I don't have much context to evaluate the new interfaces. Maybe we could another reviewer to look it over?

The only thing that struck me as odd was the casing of the V2 and V3 files. I think it's more typical for all file names to be lower case.


// MessageDecoderV2 decodes message from V2 protocol into struct.
type MessageDecoderV2 interface {
MessageDecoder
Copy link

@serprex serprex Mar 20, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why remove this? similarly, why not have DecoderV3 inherit DecoderV2? It seems this is because V3 introduces new message types, & Decode was passing here off of baseMesssage?

would it be better to pass version as a parameter to Decode?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Talking more, idea is that ParseV2 should return result of Parse like ParseV3 returns ParseV2 rather than using getCommonDecoder to have a V2 or V1 decoder where we call V2 (ignoring V1 method) if V2 implemented, otherwise call V1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants