On 21.01.25 11:48, Umar Hayat wrote:
> For XMLAttributes attribute it should have ColumnRef/Expr because
> that's the data/content we want to generate. But namespaces and xml
> tags, IMO they should be considered as part of the structure/schema of
> XML. Allowing namespaces (default or otherwise) to be generated
> arbitrarily for each record does not seem correct to me, it's like
> generating arbitrary XML using print string which does not require XML
> functions.
I'm not sure I completely get your 'print string' argument. Namespaces
are added to the element using libxml2's xmlTextWriterWriteAttributeNS
function, so we’re letting libxml2 handle whether a namespace
declaration is valid or not. Of course, there are still some extra
checks required by the SQL/XML standard.
>
> - DB2 allows XMLElements namespace but it does not allow Expr/ColumnRef.
> - Oracle Allow namespace in only XMLTable, and it does not allow
> Expr/ColumnRef.
>
> - Having SConst/String or numeric can limit the error handling at
> parsing stage which can validate the schema instead of expression
> evaluation per record, which leads to following problem at runtime:
>
> CREATE TABLE xmltab (uri TEXT);
> INSERT INTO xmltab VALUES ('good'), ('');
> SELECT XMLElement(NAME "root", XMLNamespaces(uri AS zz)) from xmltab;
> ERROR: invalid XML namespace URI for "zz"
> DETAIL: a regular XML namespace cannot be a zero-length string
>
> Imagine there millions of records and in the middle it fails.
I don't think discarding a feature just because the input data might
raise an exception in a long transaction is a strong argument here. For
your specific case, the user can always use a WHERE clause to filter out
any URIs that aren’t valid for XMLNamespace. Additionally, the
documentation already mentions this specific limitation:
"The value of a <replaceable>regular-nsuri</replaceable> cannot be a
zero-length string."
So it shouldn’t really catch anyone off guard :)
Thanks for the review!
Best, Jim
