Thread: Re: Add XMLNamespaces to XMLElement

Hi,
+1 for the enhancement.

I haven't compiled and reviewed the full patch yet, please see a few
comments from my side based on static analysis.

1. Though changes are targeted for XMLNAMESPACES for XMLElement but in
my opinion it will affect XMLTABLE as well because the
'xml_namespace_list' rule is shared now.
Adding 'NO DEFAULT' in xml_namespace_list will allow users to use it
with XMLTABLE XMLNAMESPACES as well.PostgreSQL grammar allow to
specify DEFAULT in NAMESPACE but resulting in following error:
"ERROR:  DEFAULT namespace is not supported"
What would be behavior with this change for XMLTABLE, should this be
allowed and the error messages need to be updated (may be this will
not be an error at all) or we need to restrict users to not use 'NO
DEFAULT' with XMLTable.

2. Should we reuse the 'xml_namespaces' rule for XMLTable, as the
definition is the same.

3. In this patch 'NO DEFAULT' behavior is like DEFAULT '<blank>'
(empty uri) , should not it be more like 'DEFAULT NULL' to result in
the following ?
SELECT xmlelement(NAME "root", xmlnamespaces(NO DEFAULT));
    xmlelement
------------------
<root/>

instead of

SELECT xmlelement(NAME "root", xmlnamespaces(NO DEFAULT));
    xmlelement
------------------
<root xmlns=""/>

Regards
Umar Hayat

On Sat, 21 Dec 2024 at 14:57, Pavel Stehule <pavel.stehule@gmail.com> wrote:
>
> Hi
>
> so 21. 12. 2024 v 0:51 odesílatel Jim Jones <jim.jones@uni-muenster.de> napsal:
>>
>> Hi,
>>
>> I'd like to propose the implementation of the XMLNamespaces option for
>> XMLElement.
>>
>> XMLNAMESPACES(nsuri AS nsprefix)
>> XMLNAMESPACES(DEFAULT default-nsuri)
>> XMLNAMESPACES(NO DEFAULT)
>>
>> * nsprefix:              Namespace's prefix.
>> * nsuri:                 Namespace's URI.
>> * DEFAULT default-nsuri: Specifies the DEFAULT namespace to use within
>> the scope of a namespace declaration.
>> * NO DEFAULT:            Specifies that NO DEFAULT namespace is to be
>> used within the scope of a namespace declaration.
>>
>> This basically works pretty much like XMLAttributes, but with a few more
>> restrictions (see SQL/XML:2023, 11.2 <XML lexically scoped options>):
>>
>> * XML namespace declaration shall contain at most one DEFAULT namespace
>> declaration item.
>> * No namespace prefix shall be equivalent to xml or xmlns.
>> * No namespace URI shall be identical to http://www.w3.org/2000/xmlns/
>> or to http://www.w3.org/XML/1998/namespace.
>> * The value of a namespace URI contained in an regular namespace
>> declaration item (no DEFAULT) shall not be a zero-length string.
>>
>> Examples:
>>
>> SELECT xmlelement(NAME "foo", xmlnamespaces('http://x.y' AS bar));
>>           xmlelement
>> -------------------------------
>>  <foo xmlns:bar="http://x.y"/>
>>
>> SELECT xmlelement(NAME "foo", xmlnamespaces(DEFAULT 'http://x.y'));
>>         xmlelement
>> ---------------------------
>>  <foo xmlns="http://x.y"/>
>>
>> SELECT xmlelement(NAME "foo", xmlnamespaces(NO DEFAULT));
>>    xmlelement
>> -----------------
>>  <foo xmlns=""/>
>>
>> In transformXmlExpr() it seemed convenient to use the same parameters to
>> store the prefixes and URIs as in XMLAttributes (arg_names and
>> named_args), but I am still not so sure it is the right approach. Is
>> there perhaps a better way?
>>
>> Any thoughts? Feedback welcome!
>
>
> +1
>
> Pavel
>>
>>
>> Best, Jim



--
Umar Hayat
Bitnine (https://bitnine.net/)

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

Pavel and Jim,
If that's the case, it looks good to me.
Just wanted to highlight potential issues and implementation
differences compared to other databases.

Regards
Umar Hayat