Re: PostgreSQL vs SQL/XML Standards

pá 26. 10. 2018 v 6:25 odesílatel Chapman Flack <chap(at)anastigmatix(dot)net>
napsal:

> On 10/25/18 23:16, Pavel Stehule wrote:
> >> XMLTABLE would be the headache. Using the standard name for something
> >> that ain't the standard function has not left any painless way that the
> >> standard function could be added. OTOH, it has only been in the wild
> >> since 10, so renaming it to something else (xpath_table?) will probably
> >> be more painless if done soon than it ever would be later.
> >>
> > I don't share your opinion. XMLTABLE implements subset of standard. More
> it
> > is well compatible with Oracle (in this subset).
> >
> > If we have library with XPath 2.0 or higher, we can continue with it.
>
> The difficulty here is that the expression language required by the
> standard
> is XQuery, and an XPath expression (whether 1.0 or 2.0+) can always be
> parsed as an XQuery expression. (So, /syntactically/, yes, "subset".)
>
> For XPath 2.0, that is no problem, because an XPath 2.0 expression and
> the identically-spelled XQuery expression /mean the same thing/.
>
> For XPath 1.0, it is very definitely a problem, because an XPath 1.0
> expression and the identically-spelled XQuery expression /do not mean
> the same thing/. Some of the important semantic differences are in [1].
>
> So, if a future PostgreSQL version has an XMLTABLE function that accepts
> XQuery, as the standard requires, and existing users upgrade and they have
> XMLTABLE query expressions written as XPath 1.0, those queries will be
> accepted and parsed, but they will not mean the same thing. The function
> will not be able to tell when it is being called with XQuery semantics
> intended, vs. when it is being called with XPath 1.0 semantics intended.
>

If we have a library with XQuery, then we can change the behave. But world
accepting of XQuery is not wide, unfortunately.

When I wrote and tested XMLTABLE, I found only few examples of where XQuery
was used. So first there should be any library with XQUery implementation
that can be used in Postgres. This library should be fast, well tested
without memory leaks. Elsewhere discussion is premature. I am not terrible
happy from libxml2 design, documentation, manuals - and I will not against
we can migrate to some better. On second hand - libxml2 code is working -
and it is widely used. It can be big mistake if we use Java library and if
we create dependency on Java. After, there are only few libs that doesn't
significantly better than libxml2.

> Now, perhaps there is a nicer way than renaming the function. It could
> work like overloading. Create two trivial domains over text, say xpath1
> and xquery, and have two XMLTABLE functions with different first parameter
> types. Then if you called with the expression '"cat" < "dog"'::xquery
> you would get the correct result 't', and with '"cat" < "dog"'::xpath1
> you would get the (also correct) result 'f'.
>

Probably it can works, but needs more work on Postgres infrastructure. If
you overload functions like this, then type should be used every time.

> (It would not be exactly overloading, because of the special sugared
> syntax known to the parser, but it could look like overloading, and be
> intuitive to the user.)
>
> If you have convenient access to Oracle to check compatibility, could you
> compare this query?
>
> SELECT * FROM XMLTABLE('.'
> PASSING '<sale hatsize="7" customer="alice" taxable="false"/>'
> COLUMNS
> a boolean PATH 'string("cat" < "dog")',
> b boolean PATH 'string("cat" > "dog")',
> c boolean PATH 'string(sale/@taxable = false())');
>
> (I suspect in Oracle it would also work without the string() wrappings,
> but just to make it easy, I think this way it will work in both Oracle
> and PG—that is, not error, though results may differ.)
>

I will test it.

Regards

Pavel

> -Chap
>
>
> [1]
>
> https://wiki.postgresql.org/wiki/PostgreSQL_vs_SQL/XML_Standards#Related_to_version_of_XPath
>