On 26.08.24 14:15, Pavel Stehule wrote: > I am not strongly against enhancing XMLSERIALIZE, but it can be nice > to see some wider concept first. Currently the state looks just random > - and I didn't see any serious discussion about implementation fo > SQL/XML. We don't need to be necessarily compatible with Oracle, but > it can help if we have a functionality that can be used for conversions.
Fair point. A road map definitely wouldn't hurt. Not quite sure how to start this motion though :D So far I've just picked the missing SQL/XML features that were listed in the PostgreSQL todo list and that I need for any of my projects. But I would gladly change the priorities if there is any interest in the community for specific features.
yes, "like" road map and related questions - just for XMLSERIALIZE (in this thread). I see points
1. what about behaviour of NO INDENT - the implementation is not too old, so it can be changed if we want (I think), and it is better to do early than too late
2. Are we able to implement SQL/XML syntax with libxml2?
3. Are we able to implement Oracle syntax with libxml2? And there are benefits other than higher possible compatibility?
4. Can there be some possible collision (functionality, syntax) with CANONICAL?
5. SQL/XML XMLSERIALIZE supports other target types than varchar. I can imagine XMLSERIALIZE with CANONICAL to bytea (then we don't need to force database encoding). Does it make sense? Are the results comparable?
