čt 23. 1. 2025 v 0:55 odesílatel Jim Jones <jim.jo...@uni-muenster.de> napsal:
> Hi Chapman & Robert > > Many thanks for the input > > On 22.01.25 22:35, Chapman Flack wrote: > > On 01/22/25 13:41, Robert Treat wrote: > >> So even if we are following the spec (which I think technically we may > >> not be), > > There are definite ways in which we're not following the SQL/XML spec, > > which we document in an appendix[1]. The one that matters here is that > > we just have a single XML type instead of the hierarchy of them in the > > spec, and ours corresponds to what the spec calls XML(CONTENT(ANY)). > > > > With that divergence from the spec understood, I don't see any new > > divergence in providing an XMLDOCUMENT function that just returns > > its argument. That's the correct result to return for anything that's > > a valid value of our XML type to begin with. > > > >> if no other database implements it the way we are > > There may be other systems that don't implement it at all, for which > > case I don't see any compatibility issue created because we have it > > and they do not. > > > Yeah, as long as we stick to the specification, I don’t see any issue > with including it. > > > > > > There may be systems that implement the SQL/XML type hierarchy more > > completely than we do, so that it would be possible for their > > XMLDOCUMENT to be called with an XML(SEQUENCE) argument, or with > > RETURNING SEQUENCE, both of which are things that can't happen > > in PostgreSQL. I don't see a problem in that either, as long as > > theirs produces results matching ours in the RETURNING CONTENT, > > passed an XML(CONTENT...) argument case. > > > > If another system produces results that differ, in that restricted > > domain corresponding to ours, I'd say something's nonconformant in > > that implementation. In my opinion, that would only be a problem > > for us if the system in question is an 800 lb gorilla and has many > > users relying on the differing behavior. > > > > Regarding the patch itself: I wonder if there is already, somewhere > > in the code base, a generic fmgr identity function that the pg_proc > > entry could point to. Or is there a strong project tradition in favor > > of writing a dedicated new one to use here? I'm not sure it's critical > > to have a version that tests USE_LIBXML or reports it's unsupported, > > because without support I doubt there's any way to pass it a non-null > > XML argument, and if declared STRICT it won't be called for a null one > > anyway. > > > > Regards, > > -Chap > > > > [1] https://www.postgresql.org/docs/17/xml-limits-conformance.html > > > Regarding compatibility, here is an example of how both implementations > handle single-rooted XML, non-single-rooted XML, and NULL values. > > > == DB2 [1] == > > WITH t(x) AS ( > VALUES > (xmlparse(DOCUMENT '<root><foo>bar</foo></root>')), > (xmlforest(42 AS foo, 73 AS bar)), > (NULL) > ) > SELECT xmldocument(x) FROM t; > > ---------------------------- > <root><foo>bar</foo></root> > <FOO>42</FOO><BAR>73</BAR> > I think so in this form (just forward input to output) I have no objection. There is a benefit with a) possible zero work with migration from db2, b) nobody needs to repeat a work which is a correct implementation of XMLDOCUMENT function. Maybe opened question can be implementation like classic scalar function or via XmlExpr In this moment I prefer to use XmlExpr from consistency reasons Regards Pavel - > > 3 record(s) selected. > > > > == PostgreSQL == > > WITH t(x) AS ( > VALUES > (xmlparse(DOCUMENT '<root><foo>bar</foo></root>')), > (xmlforest(42 AS foo, 73 AS bar)), > (NULL) > ) > SELECT xmldocument(x) FROM t; > > xmldocument > ----------------------------- > <root><foo>bar</foo></root> > <foo>42</foo><bar>73</bar> > > (3 rows) > > > To make it clear: ensuring this function is compatible with other > database products is IMHO beneficial (and is my primary motivation), but > it shouldn't come at the expense of violating the SQL/XML specification. > I mean, if in some edge case, another database system implemented > XMLDocument in a way that deviates from the standard, I'd argue it’s not > worth prioritizing compatibility -- assuming, of course, that we are > fully following the standard. > > > Best regards, Jim > > > 1 - https://dbfiddle.uk/G9VoHKp7 > > > >
