On Fri, Dec 19, 2025 at 9:40 AM Amit Kapila <[email protected]> wrote: > > On Fri, Dec 19, 2025 at 4:38 AM Masahiko Sawada <[email protected]> wrote: > > > > On Thu, Dec 18, 2025 at 1:09 AM Dilip Kumar <[email protected]> wrote: > > > > > > > > 2) In catalog I am storing the "conflict_log_format" option as a text > > > field, is there any better way so that we can store in fixed format > > > maybe enum value as an integer we can do e.g. from below enum we can > > > store the integer value in system catalog for "conflict_log_format" > > > field, not sure if we have done such think anywhere else? > > > > > > typedef enum ConflictLogFormat > > > { > > > CONFLICT_LOG_FORMAT_DEFAULT = 0, > > > CONFLICT_LOG_FORMAT_LOG, > > > CONFLICT_LOG_FORMAT_TABLE, > > > CONFLICT_LOG_FORMAT_BOTH > > > } ConflictLogFormat; > > > > How about making conflict_log_format accept a list of destinations > > instead of having the 'both' option in case where we might add more > > destination options in the future? > > > > It seems to me that conflict_log_destination sounds better. > > > > Yeah, this is worth considering. But say, we need to extend it so that > the conflict data goes in xml format file instead of standard log then > won't it look a bit odd to specify via conflict_log_destination. I > thought we could name it similar to the existing > auto_explain.log_format. >
One option could be to separate destination and format: conflict_log_history.destination : log/table conflict_log_history.format : xml/json/text etc Another option could be to use a single parameter, 'conflict_log_destination', with values such as: table, xmllog, jsonlog, stderr/textlog (where stderr corresponds to logging to log/postgresql.log, similar to log_destination at [1]). I prefer this approach. [1]: https://www.postgresql.org/docs/18/runtime-config-logging.html thanks Shveta
