On Mon, Jun 22, 2020 at 10:13 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Big -1 on that. COPY is not for general-purpose data transformation. The more unrelated features we load onto it, the slower it will get, and probably also the more buggy and unmaintainable.
what new format handling takes to add regards to performance is a check to a few place and I don’t think that have noticeable performance impact and as far as I can see copy is extendable by design and I don’t think adding additional format will be a huge undertaking
There's also a really fundamental mismatch, in that COPY is designed to do row-by-row processing with essentially no cross-row state. How would you square that with the inherently nested nature of XML?
In xml case the difference is row delimiter . In xml mode user specifies row delimiter tag name and starting from start tag of specified name up to its end tag treated as single row and every text content in between will be our columns value filed
The big-picture question here, though, is why expend effort on XML at all? It seems like JSON is where it's at these days for that problem space.
there are a legacy systems and I think xml is still popular
