Re: Proposal: Conflict log history table for Logical Replication
От | Dilip Kumar |
---|---|
Тема | Re: Proposal: Conflict log history table for Logical Replication |
Дата | |
Msg-id | CAFiTN-th=aTFNDUATrKFBtBpxkP8saKhXzsSWXyPB9gC=fBD-g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Proposal: Conflict log history table for Logical Replication (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: Proposal: Conflict log history table for Logical Replication
|
Список | pgsql-hackers |
On Mon, Aug 18, 2025 at 12:25 PM Amit Kapila <amit.kapila16@gmail.com> wrote: > > On Fri, Aug 15, 2025 at 2:31 PM Dilip Kumar <dilipbalaut@gmail.com> wrote: > > > > Yet another question is about table names, whether we keep some > > standard name like conflict_log_history_$subid or let users pass the > > name. > > > > It would be good if we can let the user specify the table_name and if > she didn't specify then use an internally generated name. I think it > will be somewhat similar to slot_name. However, in this case, there is > one challenge which is how can we decide whether the schema of the > user provided table_name is correct or not? Do we compare it with the > standard schema we are planning to use? Ideally we can do that, if you see in this thread [1] there is a patch [2] which first try to validate the table schema and if it doesn't exist it creates it on its own. And it seems fine to me. > One idea to keep things simple for the first version is that we allow > users to specify the table_name for storing conflicts but the table > should be created internally and if the same name table already > exists, we can give an ERROR. Then we can later extend the > functionality to even allow storing conflicts in pre-created tables > with more checks about its schema. That's fair too. I am wondering what namespace we should create this user table in. If we are creating internally, I assume the user should provide a schema qualified name right? [1] https://www.postgresql.org/message-id/flat/752672.1699474336%40sss.pgh.pa.us#b8450be5645c4252d7d02cf7aca1fc7b [2] https://www.postgresql.org/message-id/attachment/152792/v8-0001-Add-a-new-COPY-option-SAVE_ERROR.patch -- Regards, Dilip Kumar Google
В списке pgsql-hackers по дате отправления: