Options defaults are not very sensible about wal2json

[eulerto]

@dvarrazzo I agree that xids and lsn should have the same default. It is inconsistent. Do we favor replication system (those who will find this information useful) or system that expose data to some interface (those who doesn't care about transaction knowledge)?
There is a bug in the write-in-chunks code. It should emit valid JSON. It is useful for cases where you don't want to hold a huge transaction because it would consume a lot of server memory (see issue #4).

[dvarrazzo]

@eulerto My personal view: I totally favour a system that doesn't care about the absolute identity of the transaction. I see this project as a nimble, clever plugin to get a stream of changes from a database for a receiver to do whatever manipulation it wants. People wanting a replication solution should rather use something more complete such as pglogical.

[eulerto]

@dvarrazzo I agree with your suggestion (include-xids = false) so I merged in #18. I'm not sure about write_in_chunks but decided to merge your suggestion because huge transactions are rare.

[rugging24]

@eulerto "... because huge transactions are rare" not exactly true. I come across those more frequently than you may imagine . Especially in cases where huge changes are made within a function. And these are essentially captured as a single transaction. Without the write-in-chunk feature of your plugin I wouldn't have been able to manage situations like that.
Just like @dvarrazzo mentioned "People wanting a replication solution should rather use something more complete such as pglogical.". In my case this is not used as a replication solution but as a change capture solution. So please reconsider different options before taking out that functionality .

[rugging24]

... plus when write-in-chunks is enabled , the format emitted is pretty consistent .
"{"change":[" at the beginning of the transaction and
"]}" at the end of it.
And everything in between are valid Json objects. One could easily find a work-around with this in ones client. Which is what I do in my case.

[eulerto]

@rugging24 Those features weren't removed. The default values were changed. From now on, if you want to include xids into 'changes' or that you want to write in chunks, you should explicitly inform that. For example:
pg_recvlogical -d postgres --slot test_slot --start -o include-xids=1 -o write-in-chunks=1 -f -

or via SQL:

SELECT data FROM pg_logical_slot_get_changes('test_slot', NULL, NULL, 'include-xids', '1', 'write-in-chunks', '1');