New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Provide a primary key flag for columns #43
Comments
oldkeys. However, the concept of row identification is wider than primary key (ref REPLICA IDENTITY). We can use the full row, an unique index, or primary key to identity a row. |
I can use |
I'm not following you. Why would you use |
Please look at http://debezium.io/docs/connectors/postgresql/, section |
I read the docs but I'm not sure what kind of problem you are trying to solve. For updates, we provide key and new tuple. Do you want the old tuple too? |
Yes, exactly! |
@jpechane is there any interest in this feature? |
@eulerto Hi, we still have a strong interest in this feature. Unfortunately our skillset blocks us from implementing and providing a PR |
@eulerto, my company (Braintree) has actually started implementing this feature in an internal fork. Our idea was to change the definition of Here's an outline of the scenarios: InsertIf replica identity is DEFAULT, FULL, or an index:
UpdateIf replica identity is DEFAULT:
If replica identity is FULL:
If replica identity is an index:
DeleteIf replica identity is DEFAULT:
If replica identity is FULL:
If replica identity is an index:
I'm sure there are some weird edge cases that I didn't mention, but in summary: To transition from DEFAULT to FULL, this approach makes a lot of sense for our use case, as it simply introduces a new field while I'd love to hear your thoughts on this proposal! Thanks! |
Hey @rkrage, did you ever end up publishing this work somewhere? |
We've had some discussions about publishing our internal fork, but I'm not sure where we landed on it. I'll bring it up again and get back to you! Also, we've been running this feature in production for the past several months with no issues 😃 |
Hey @rkrage, did you ever decide to publish your work? Also, does the feature work with format-version 2? I'm specifically interested in how you were able to get the entire tuple for DELETE records. |
@deanrabinowitz4, we haven't been able to publish our work, unfortunately. But I didn't think we did anything special to get the entire tuple for DELETEs. I thought you just needed to set replica identity to full. As far as determining the PK when replica identity is full, I believe this is the code that inspired our work: https://github.com/postgres/postgres/blob/7551d9bc408c2402a8558367ee950ca403e25b37/contrib/tcn/tcn.c#L121-L139 Our fork doesn't currently support format version 2. We were hoping the open-source version would evolve to suit our needs, and it looks like it's getting close. @eulerto, we had previously discussed exposing the PK in the version 2 proposal: #110 (comment) Is that still in the works? Thanks! |
Since this is a popular request, I developed a patch to add primary key information (both formats). If I have some spare time to improve test coverage for this feature, I will commit it this week. |
Done on commit 3511384 |
When the event is processed downstream it is important to know what columns forms the primary key. Could you please provide a flag for columns that says that it is a part of primary key?
The text was updated successfully, but these errors were encountered: