Re: Decomposing xml into table

Hey Tom

On Mon, Jun 22, 2020 at 10:13 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

regards
Surafel