PostgreSQL vs SQL/XML Standards

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
112 messages Options
123456
Reply | Threaded
Open this post in threaded view
|

Re: House style for DocBook documentation?

Joshua D. Drake
On 1/21/19 8:46 AM, Chapman Flack wrote:

> On 01/21/19 09:12, Alvaro Herrera wrote:
>
>>> (thinks to self half-seriously about an XSL transform for generating
>>> printed output that could preserve link-texted links, add raised numbers,
>>> and produce a numbered URLs section at the back)
>> Well, if you have the time and inclination, and you think such changes
>> are improvements, feel free to propose them.  Do keep in mind we have a
>> number of outputs that would be good to keep consistent.
> Well, "consistent" what I was half-thinking about, FSVO "consistent".
>
> For me, if I'm looking at an online document, I would prefer to see
> the descriptive text of the link, rather than a long jaggy URL. If I
> want to see the URL, I can hover over it, and if I want to go there,
> I can click it.
>
> But the point's well taken that in /printed output/, that's of no use.
> Which is, in a sense, an inconsistency: in one format, you can follow the
> links, while in another, you're out of luck.
>
> Maybe a simpler transform for printed output, rather than collecting
> all URLs into one section at the back, would just be to follow any
> <ulink> that has link text with a <footnote> containing the same ulink
> without the link text, so it shows the URL, and that would be right at
> the bottom of the same 'page'.
>
> That'd be an introductory XSL exercise....
>
> In practice, applying such a transform "for printed output" would
> probably mean applying it when generating PDF output, which of course
> can also be viewed online (and probably most often is, these days).

I don't think that is a good idea. PDFs have had the ability to embed
hyperlinks under descriptive text for years. If we are going to expand
links for printed output, we should have a specific build / modification
to the make file for printed output. I also wonder if we are trying to
solve the 1% problem here. Who is really going to "print" our docs? If
they do print the docs, they are likely not going to "type in" a long
URL. They are going to go online (or to the PDF) and click the link that
they saw within the printed page.

JD

--
Command Prompt, Inc. || http://the.postgres.company/ || @cmdpromptinc
PostgreSQL centered full stack support, consulting and development.
Advocate: @amplifypostgres || Learn and Network: https://postgresconf.org
***  A fault and talent of mine is to tell it exactly how it is.  ***


Reply | Threaded
Open this post in threaded view
|

Re: House style for DocBook documentation?

Alvaro Herrera-9
In reply to this post by Chapman Flack
On 2019-Jan-21, Chapman Flack wrote:

> But the point's well taken that in /printed output/, that's of no use.
> Which is, in a sense, an inconsistency: in one format, you can follow the
> links, while in another, you're out of luck.
>
> Maybe a simpler transform for printed output, rather than collecting
> all URLs into one section at the back, would just be to follow any
> <ulink> that has link text with a <footnote> containing the same ulink
> without the link text, so it shows the URL, and that would be right at
> the bottom of the same 'page'.

Of course, the text would also be clickable, right?  I think putting the
URL in a footnote is good in that case; it works both on screen and on
paper, which should alleviate JD's concerns.

> I wouldn't think it important to apply the same treatment when making HTML.

Right, only PDF.

--
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Reply | Threaded
Open this post in threaded view
|

Re: House style for DocBook documentation?

Chapman Flack
In reply to this post by Joshua D. Drake
On 01/21/19 12:07, Joshua D. Drake wrote:
> Who is really going to "print" our docs? If they do print the
> docs, they are likely not going to "type in" a long URL.

QR code in footnote (ducks and runs).

Reply | Threaded
Open this post in threaded view
|

Re: House style for DocBook documentation?

Joshua D. Drake
In reply to this post by Alvaro Herrera-9
On 1/21/19 10:01 AM, Alvaro Herrera wrote:

> On 2019-Jan-21, Chapman Flack wrote:
>
>> But the point's well taken that in /printed output/, that's of no use.
>> Which is, in a sense, an inconsistency: in one format, you can follow the
>> links, while in another, you're out of luck.
>>
>> Maybe a simpler transform for printed output, rather than collecting
>> all URLs into one section at the back, would just be to follow any
>> <ulink> that has link text with a <footnote> containing the same ulink
>> without the link text, so it shows the URL, and that would be right at
>> the bottom of the same 'page'.
> Of course, the text would also be clickable, right?  I think putting the
> URL in a footnote is good in that case; it works both on screen and on
> paper, which should alleviate JD's concerns.

Yeah I could see that. I thought about that but was wondering if it was
possible to auto cite?

JD


>
>> I wouldn't think it important to apply the same treatment when making HTML.
> Right, only PDF.
>

--
Command Prompt, Inc. || http://the.postgres.company/ || @cmdpromptinc
PostgreSQL centered full stack support, consulting and development.
Advocate: @amplifypostgres || Learn and Network: https://postgresconf.org
***  A fault and talent of mine is to tell it exactly how it is.  ***


Reply | Threaded
Open this post in threaded view
|

Re: House style for DocBook documentation?

Joshua D. Drake
In reply to this post by Chapman Flack
On 1/21/19 10:11 AM, Chapman Flack wrote:
> On 01/21/19 12:07, Joshua D. Drake wrote:
>> Who is really going to "print" our docs? If they do print the
>> docs, they are likely not going to "type in" a long URL.
> QR code in footnote (ducks and runs).

Funny, although I know why you said that. I don't think it is that bad
of an idea. Everyone uses QR Codes now. Have a QR code that
automatically opens a page that lists all the expanded links based on
the page it is placed?

That is pretty cool but I am not sure if that is something that would
happen in this round.

JD


>

--
Command Prompt, Inc. || http://the.postgres.company/ || @cmdpromptinc
PostgreSQL centered full stack support, consulting and development.
Advocate: @amplifypostgres || Learn and Network: https://postgresconf.org
***  A fault and talent of mine is to tell it exactly how it is.  ***


Reply | Threaded
Open this post in threaded view
|

Re: House style for DocBook documentation?

Alvaro Herrera-9
In reply to this post by Joshua D. Drake
On 2019-Jan-21, Joshua D. Drake wrote:

> On 1/21/19 10:01 AM, Alvaro Herrera wrote:
> > On 2019-Jan-21, Chapman Flack wrote:
> >
> > > But the point's well taken that in /printed output/, that's of no use.
> > > Which is, in a sense, an inconsistency: in one format, you can follow the
> > > links, while in another, you're out of luck.
> > >
> > > Maybe a simpler transform for printed output, rather than collecting
> > > all URLs into one section at the back, would just be to follow any
> > > <ulink> that has link text with a <footnote> containing the same ulink
> > > without the link text, so it shows the URL, and that would be right at
> > > the bottom of the same 'page'.
> > Of course, the text would also be clickable, right?  I think putting the
> > URL in a footnote is good in that case; it works both on screen and on
> > paper, which should alleviate JD's concerns.
>
> Yeah I could see that. I thought about that but was wondering if it was
> possible to auto cite?

Sorry, what do you mean with auto cite?  Put all links at the end of the
section/chapter/book?  That seems less usable to me (you have to find
out the page where the links appear, and make sure to print the right
pages)

--
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Reply | Threaded
Open this post in threaded view
|

Re: House style for DocBook documentation?

Chapman Flack
In reply to this post by Joshua D. Drake
On 01/21/19 13:14, Joshua D. Drake wrote:
>> Of course, the text would also be clickable, right?  I think putting the
>> URL in a footnote is good in that case; it works both on screen and on
>> paper, which should alleviate JD's concerns.
>
> Yeah I could see that. I thought about that but was wondering if it was

It looks like the easiest way to integrate such a behavior into the
current Makefile would be not as a separate DocBook->DocBook transform
in advance, but simply by editing the existing stylesheet-fo.xsl that
produces the FO input for generating the PDF.

That would mean learning some FO, which I've wanted to do for a while,
but haven't yet, so it stops looking like something I might experiment
with this afternoon. OTOH, it could mean more flexibility in how the
presentation should look.

I note in passing that the google result [1] is nonempty....

-Chap

[1] https://www.google.com/search?q=xsl-fo+qr+code

Reply | Threaded
Open this post in threaded view
|

Re: PostgreSQL vs SQL/XML Standards

Chapman Flack
In reply to this post by Pavel Stehule
Hi,

In two places in the XMLTABLE implementation (XmlTableFetchRow, iterating
through a nodeset returned by the row_expression, and XmlTableGetValue,
going through a nodeset returned by the column_expression), the iteration
proceeds in index order through xpathobj->nodesetval->nodeTab.

The same happens in the older xml_xpathobjtoxmlarray, producing the array
result of the xpath() function.

In <libxml/xpath.h> one finds this unsettling comment:

 xmlNodePtr *nodeTab; /* array of nodes in no particular order */


So far, no matter what oddball XPath expressions I think up, nodeTab
does seem to end up in document order. It would be comforting to document
that, but the comment suggests it might not be guaranteed.

Are you aware of any statement I might have missed in the libxml docs,
where they commit to XPath evaluation returning a nodeset where nodeTab
has a predictable order? If there is a statement to that effect somewhere,
it might be worth citing in a comment in xml.c.

Regards,
-Chap



Here is a fairly oddball query, generating an XML document with about
3k names in descending order, partitioning those elements into subsets
having the same second character of the name, and unioning those back
together. You'd sort of expect that to produce a result nodeTab in goofy
order if anything could, but no, the results seem verifiably in descending
order every time, suggesting the result nodeTab is indeed being put
in document order before the XPath evaluator returns. If only they would
document that.

WITH nodeset_order_check(name, prev_name) AS (
 SELECT
  x, lag(x) OVER (ROWS BETWEEN 1 PRECEDING AND CURRENT ROW)
  FROM
   (SELECT
     string_agg(DISTINCT
      'x/n[substring(.,2,1) = "' || substring(proname from 2 for 1) || '"]',
      '|')
     FROM pg_proc) AS rowx(rowx),
   (SELECT
     XMLELEMENT(NAME x,
                XMLAGG(XMLELEMENT(NAME n, proname) ORDER BY proname DESC))
     FROM pg_proc) AS src(src),
   XMLTABLE(rowx PASSING src COLUMNS x text PATH '.')
)
SELECT every(prev_name >= name IS NOT FALSE) FROM nodeset_order_check;
 every
-------
 t
(1 row)

Reply | Threaded
Open this post in threaded view
|

Re: PostgreSQL vs SQL/XML Standards

Chapman Flack
In reply to this post by Pavel Stehule
Hi,

On 01/21/19 01:33, Pavel Stehule wrote:
> ne 20. 1. 2019 23:13 odesílatel Chapman Flack <[hidden email]>
> napsal:

>> form (whether or not the word LATERAL is used), and re-executes xmltable
>> whenever the referenced column value changes. In that case, whether the
>> default argument is evaluated at function entry or later doesn't seem
>> to matter: the function is re-executed, so evaluating the new default
>> at the time of entry is sufficient.
>
> it has sense only for volatile functions. it was not often. On second hand
> deferred evaluation shoul not be a problem, and more, it is evaluated only
> when it is necessary, what is more sensible for me.

That makes sense. I trimmed the language about input rows and referring to
earlier columns, and put more emphasis on the usefulness of evaluating
volatile functions only when needed.

I am:

- re-attaching xmltable-xpath-result-processing-bugfix-5.patch unchanged
  (just so CF app does not lose track)

- re-attaching xmltable-xmlexists-passing-mechanisms-1.patch unchanged

- attaching for the first time xml-functions-type-docfix-1.patch

The doc patch is made to go on top of the passing-mechanisms patch
(there were some doc changes in passing-mechanisms, changed again in
the new patch to be links to the added Limits and Compatibility section).

I hope the patched docs describe accurately what we have at this point.

Regards,
-Chap

xmltable-xpath-result-processing-bugfix-5.patch (14K) Download Attachment
xmltable-xmlexists-passing-mechanisms-1.patch (5K) Download Attachment
xml-functions-type-docfix-1.patch (30K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: PostgreSQL vs SQL/XML Standards

Pavel Stehule


pá 25. 1. 2019 v 5:46 odesílatel Chapman Flack <[hidden email]> napsal:
Hi,

On 01/21/19 01:33, Pavel Stehule wrote:
> ne 20. 1. 2019 23:13 odesílatel Chapman Flack <[hidden email]>
> napsal:

>> form (whether or not the word LATERAL is used), and re-executes xmltable
>> whenever the referenced column value changes. In that case, whether the
>> default argument is evaluated at function entry or later doesn't seem
>> to matter: the function is re-executed, so evaluating the new default
>> at the time of entry is sufficient.
>
> it has sense only for volatile functions. it was not often. On second hand
> deferred evaluation shoul not be a problem, and more, it is evaluated only
> when it is necessary, what is more sensible for me.

That makes sense. I trimmed the language about input rows and referring to
earlier columns, and put more emphasis on the usefulness of evaluating
volatile functions only when needed.

I am:

- re-attaching xmltable-xpath-result-processing-bugfix-5.patch unchanged
  (just so CF app does not lose track)

- re-attaching xmltable-xmlexists-passing-mechanisms-1.patch unchanged

- attaching for the first time xml-functions-type-docfix-1.patch

The doc patch is made to go on top of the passing-mechanisms patch
(there were some doc changes in passing-mechanisms, changed again in
the new patch to be links to the added Limits and Compatibility section).

I hope the patched docs describe accurately what we have at this point.

looks well

Pavel


Regards,
-Chap
Reply | Threaded
Open this post in threaded view
|

Re: House style for DocBook documentation?

Peter Eisentraut-6
In reply to this post by Chapman Flack
On 19/01/2019 21:24, Chapman Flack wrote:
> (thinks to self half-seriously about an XSL transform for generating
> printed output that could preserve link-texted links, add raised numbers,
> and produce a numbered URLs section at the back)

External links already create footnotes in the PDF output.  Is that
different from what you are saying?

--
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Reply | Threaded
Open this post in threaded view
|

Re: House style for DocBook documentation?

Chapman Flack
On 01/25/19 09:01, Peter Eisentraut wrote:
> On 19/01/2019 21:24, Chapman Flack wrote:
>> (thinks to self half-seriously about an XSL transform for generating
>> printed output that could preserve link-texted links, add raised numbers,
>> and produce a numbered URLs section at the back)
>
> External links already create footnotes in the PDF output.  Is that
> different from what you are saying?

That might, only, indicate that I was just thinking aloud in email and
had not gone and checked in PDF output to see how the links were handled.

Yes, it could very possibly indicate that.

If they are already processed that way, does that mean the

o  Do not use text with <ulink> so the URL appears in printed output

in README.links should be considered obsolete, and removed even, and
doc authors should feel free to put link text in <ulink> without
hesitation?

Regards,
-Chap

Reply | Threaded
Open this post in threaded view
|

Re: PostgreSQL vs SQL/XML Standards

Chapman Flack
In reply to this post by Pavel Stehule
On 01/25/19 00:45, Pavel Stehule wrote:
> pá 25. 1. 2019 v 5:46 odesílatel Chapman Flack <[hidden email]>
> napsal:
>> I am:
>> - re-attaching xmltable-xpath-result-processing-bugfix-5.patch unchanged
>>   (just so CF app does not lose track)
>> - re-attaching xmltable-xmlexists-passing-mechanisms-1.patch unchanged
>> - attaching for the first time xml-functions-type-docfix-1.patch
>>
>> The doc patch is made to go on top of the passing-mechanisms patch

Realized xmltable-xmlexists-passing-mechanisms-1.patch didn't add
a regression test.  Here attaching (or re-attaching):

- xmltable-xpath-result-processing-bugfix-5.patch - unchanged
- xmltable-xmlexists-passing-mechanisms-2.patch - now with test
- xml-functions-type-docfix-1.patch - unchanged

I'll venture a review opinion that all of this applies, builds, and passes
check-world on top of 18c0da8, and that, of the issues I had identified at
the start of this thread, these changes resolve the ones they set out to
resolve.

But the second two patches are my own work, so another reviewer is needed.
The passing-mechanisms patch is tiny while the docfix patch is not, so
there's an opening for a reviewer with an interest in documentation. :)

There is still nothing in this patch set to address [1], though that
also seems worth doing, perhaps in another patch, and probably not
difficult, perhaps needing only a regex.

And of course we're still saddled with all the unfixable limits
of XPath 1.0; this patch set is fixing a few peripheral fixable things
around that.

-Chap


[1] https://www.postgresql.org/message-id/5BD1C44B.6040300%40anastigmatix.net

xmltable-xpath-result-processing-bugfix-5.patch (14K) Download Attachment
xmltable-xmlexists-passing-mechanisms-2.patch (8K) Download Attachment
xml-functions-type-docfix-1.patch (30K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: PostgreSQL vs SQL/XML Standards

Chapman Flack
The following review has been posted through the commitfest application:
make installcheck-world:  tested, passed
Implements feature:       tested, passed
Spec compliant:           not tested
Documentation:            not tested

As the reporter of the issues raised in this email thread, I've reviewed the first patch
and contributed the second and third.

WHAT THE PATCHES DO:

xmltable-xpath-result-processing-bugfix-5.patch contains code changes correcting
a subset of the issues that were raised in this email thread.

xmltable-xmlexists-passing-mechanisms-2.patch adjusts the grammar to allow the XML
parameter passing mechanism BY VALUE as well as BY REF. Both are ignored, but
formerly BY VALUE was a syntax error, which was unintuitive considering that BY VALUE
is the passing mechanism PostgreSQL implements (XML node identities are not preserved).

xml-functions-type-docfix-1.patch conforms the documentation to reflect the changes in
this patch set and the limitations identified in this thread.

WHAT I HAVE REVIEWED:

I have applied all three patches over 18c0da8 and confirmed that installcheck-world passes
and that the code changes resolve the issues they set out to resolve.

I've made no entry for "spec compliant" because the question is moot; the spec is written
in terms of the XQuery language, types, and concepts, and these facilities in PG are
implemented on XPath 1.0, which doesn't have those. But the changes in this patch set
do make the PG behaviors more, well, closely analogous to the way the spec compliant
functions would behave.

WHAT I HAVE NOT REVIEWED:

The passing-mechanisms and docfix patches are my own work, so there should be another
reviewer who is not me. I've looked closely at the technical, SQL/XML behavior aspects already,
but a reviewer with an eye for documentation would be welcome.

I'll venture my opinion that this is ready-for-committer to the extent of my own review, but will
leave the status at needs-review for a not-me reviewer to update.
Reply | Threaded
Open this post in threaded view
|

Re: PostgreSQL vs SQL/XML Standards

Pavel Stehule
Hi

so 26. 1. 2019 v 4:25 odesílatel Chapman Flack <[hidden email]> napsal:
The following review has been posted through the commitfest application:
make installcheck-world:  tested, passed
Implements feature:       tested, passed
Spec compliant:           not tested
Documentation:            not tested

maybe more simple will be work with original commitfest subscriptions. I can do review of xmltable-xmlexists-passing-mechanisms-2.patch. Documentation review will be harder - I am not a native speaker and I have not a necessary knowledges of XQuery (probably only you have this knowledge).
 

As the reporter of the issues raised in this email thread, I've reviewed the first patch
and contributed the second and third.

WHAT THE PATCHES DO:

xmltable-xpath-result-processing-bugfix-5.patch contains code changes correcting
a subset of the issues that were raised in this email thread.

xmltable-xmlexists-passing-mechanisms-2.patch adjusts the grammar to allow the XML
parameter passing mechanism BY VALUE as well as BY REF. Both are ignored, but
formerly BY VALUE was a syntax error, which was unintuitive considering that BY VALUE
is the passing mechanism PostgreSQL implements (XML node identities are not preserved).

xml-functions-type-docfix-1.patch conforms the documentation to reflect the changes in
this patch set and the limitations identified in this thread.

WHAT I HAVE REVIEWED:

I have applied all three patches over 18c0da8 and confirmed that installcheck-world passes
and that the code changes resolve the issues they set out to resolve.

I've made no entry for "spec compliant" because the question is moot; the spec is written
in terms of the XQuery language, types, and concepts, and these facilities in PG are
implemented on XPath 1.0, which doesn't have those. But the changes in this patch set
do make the PG behaviors more, well, closely analogous to the way the spec compliant
functions would behave.

WHAT I HAVE NOT REVIEWED:

The passing-mechanisms and docfix patches are my own work, so there should be another
reviewer who is not me. I've looked closely at the technical, SQL/XML behavior aspects already,
but a reviewer with an eye for documentation would be welcome.

I'll venture my opinion that this is ready-for-committer to the extent of my own review, but will
leave the status at needs-review for a not-me reviewer to update.
Reply | Threaded
Open this post in threaded view
|

Re: PostgreSQL vs SQL/XML Standards

Chapman Flack
In reply to this post by Chapman Flack
On 01/25/19 19:37, Chapman Flack wrote:
> There is still nothing in this patch set to address [1], though that
> also seems worth doing, perhaps in another patch, and probably not
> difficult, perhaps needing only a regex.

Heck, it could be even simpler than that. If some XML input has a DTD,
the attempt to parse it as 'content' with libxml is sure to fail early
in the parse (because that's where the DTD is found). If libxml reports
enough error detail to show it failed because of a DTD—and it appears to:

DETAIL:  line 1: StartTag: invalid element name
<!DOCTYPE foo>

—then simply recognize that error and reparse as 'document' on the spot.
The early-failing first parse won't have cost much, and there is probably
next to nothing to gain by trying to be any more clever.

The one complication might that there seem to be versions of libxml that
report error detail differently (hence the variant regression test expected
files), so the code might have to recognize a couple different forms.

-Chap

> [1] https://www.postgresql.org/message-id/5BD1C44B.6040300%40anastigmatix.net


Reply | Threaded
Open this post in threaded view
|

Re: PostgreSQL vs SQL/XML Standards

Chapman Flack
In reply to this post by Pavel Stehule
On 01/25/19 22:53, Pavel Stehule wrote:

> Documentation review will be harder - I am not a native speaker and I have
> not a necessary knowledges of XQuery (probably only you have this
> knowledge).

The doc patch is enough that I think it would be ideal to somehow attract
a native speaker who has interest in documentation to review it.
Even if that is someone without much XQuery-specific knowledge—I'll happily
answer whatever questions they ask about that. :)

-Chap

Reply | Threaded
Open this post in threaded view
|

Re: House style for DocBook documentation?

Peter Eisentraut-6
In reply to this post by Chapman Flack
On 25/01/2019 15:37, Chapman Flack wrote:

>> External links already create footnotes in the PDF output.  Is that
>> different from what you are saying?
> That might, only, indicate that I was just thinking aloud in email and
> had not gone and checked in PDF output to see how the links were handled.
>
> Yes, it could very possibly indicate that.
>
> If they are already processed that way, does that mean the
>
> o  Do not use text with <ulink> so the URL appears in printed output
>
> in README.links should be considered obsolete, and removed even, and
> doc authors should feel free to put link text in <ulink> without
> hesitation?

I think it's obsolete, yes.

--
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Reply | Threaded
Open this post in threaded view
|

Re: PostgreSQL vs SQL/XML Standards

Pavel Stehule
In reply to this post by Chapman Flack


so 26. 1. 2019 v 1:38 odesílatel Chapman Flack <[hidden email]> napsal:
On 01/25/19 00:45, Pavel Stehule wrote:
> pá 25. 1. 2019 v 5:46 odesílatel Chapman Flack <[hidden email]>
> napsal:
>> I am:
>> - re-attaching xmltable-xpath-result-processing-bugfix-5.patch unchanged
>>   (just so CF app does not lose track)
>> - re-attaching xmltable-xmlexists-passing-mechanisms-1.patch unchanged
>> - attaching for the first time xml-functions-type-docfix-1.patch
>>
>> The doc patch is made to go on top of the passing-mechanisms patch

Realized xmltable-xmlexists-passing-mechanisms-1.patch didn't add
a regression test.  Here attaching (or re-attaching):

- xmltable-xpath-result-processing-bugfix-5.patch - unchanged
- xmltable-xmlexists-passing-mechanisms-2.patch - now with test
- xml-functions-type-docfix-1.patch - unchanged

I'll venture a review opinion that all of this applies, builds, and passes
check-world on top of 18c0da8, and that, of the issues I had identified at
the start of this thread, these changes resolve the ones they set out to
resolve.

But the second two patches are my own work, so another reviewer is needed.
The passing-mechanisms patch is tiny while the docfix patch is not, so
there's an opening for a reviewer with an interest in documentation. :)

There is still nothing in this patch set to address [1], though that
also seems worth doing, perhaps in another patch, and probably not
difficult, perhaps needing only a regex.

And of course we're still saddled with all the unfixable limits
of XPath 1.0; this patch set is fixing a few peripheral fixable things
around that.


I am sending a review of these patches

xmltable-xpath-result-processing-bugfix-5.patch - I'll skip it - just all tests passed

xmltable-xmlexists-passing-mechanisms-2.patch - this patch introduce new PASSING mechanism BY VALUE - it is just syntactic sugar due compatibility with standard. It is unhappy so previous implementation was broken and introduced "BY REF" instead "BY VALUE", but this bug should be fixed 10 years ago. It change nothing, all tests passed and the documentation looks ok.

Last patch is documentation only patch - I am thinking so the difference and limits our implementation of XPath based functions are described well and correctly.

I'll mark this patch as ready for commiters.

Regards

Pavel
 
-Chap


[1] https://www.postgresql.org/message-id/5BD1C44B.6040300%40anastigmatix.net
Reply | Threaded
Open this post in threaded view
|

Re: PostgreSQL vs SQL/XML Standards

Michael Paquier-2
On Thu, Jan 31, 2019 at 04:26:31PM +0100, Pavel Stehule wrote:
> I'll mark this patch as ready for commiters.

For now I have moved the patch to the next CF, with the same status.
--
Michael

signature.asc (849 bytes) Download Attachment
123456