proposal - Default namespaces for XPath expressions (PostgreSQL 11)

Started by Pavel Stehuleabout 9 years ago35 messageshackers
Jump to latest
#1Pavel Stehule
pavel.stehule@gmail.com

Hi

This proposal is followup of implementation of XMLTABLE.

Lot of XML documents has assigned document namespace.

<rows xmlns="http://x.y&quot;&gt;&lt;row&gt;&lt;a&gt;10&lt;/a&gt;&lt;/row&gt;&lt;/rows&gt;

For these XML document any search path must use schema "http://x.y&quot;. This
is not too intuitive, and from XMLTABLE usage is not too user friendly,
because the default column path (same like column name) cannot be used. A
solution of this issue is default namespace - defined in SQL/XML.

example - related to previous xml

without default namespace:
XMLTABLE(NAMESPACES('http://x.y&#39; AS aux),
'/aux:rows/aux:row' PASSING ...
COLUMNS a int PATH 'aux:a')

with default namespace
XMLTABLE(NAMESPACES(DEFAULT 'http://x.y&#39;),
'/rows/row' PASSING ...
COLUMNS a int);

Unfortunately the libxml2 doesn't support default namespaces in XPath
expressions. Because the libxml2 functionality is frozen, there is not big
chance for support in near future. A implementation is not too hard -
although it requires simple XPath expressions state translator.

The databases with XMLTABLE implementation supports default namespace for
XPath expressions.

The patch for initial implementation is attached.

Regards

Pavel

Attachments:

xml-xpath-default-ns.patchtext/x-patch; charset=US-ASCII; name=xml-xpath-default-ns.patchDownload+380-9
#2Kyotaro Horiguchi
horikyota.ntt@gmail.com
In reply to: Pavel Stehule (#1)
Re: proposal - Default namespaces for XPath expressions (PostgreSQL 11)

Hello, this patch have been ignored for a long time since its proposal...

At Sat, 11 Mar 2017 20:44:31 +0100, Pavel Stehule <pavel.stehule@gmail.com> wrote in <CAFj8pRB+WDyDcZyGmfRdJ0HOoXugeaL-KNFeK9YA5Z10JN9qfA@mail.gmail.com>

Hi

This proposal is followup of implementation of XMLTABLE.

Lot of XML documents has assigned document namespace.

<rows xmlns="http://x.y&quot;&gt;&lt;row&gt;&lt;a&gt;10&lt;/a&gt;&lt;/row&gt;&lt;/rows&gt;

For these XML document any search path must use schema "http://x.y&quot;. This
is not too intuitive, and from XMLTABLE usage is not too user friendly,
because the default column path (same like column name) cannot be used. A
solution of this issue is default namespace - defined in SQL/XML.

example - related to previous xml

without default namespace:
XMLTABLE(NAMESPACES('http://x.y&#39; AS aux),
'/aux:rows/aux:row' PASSING ...
COLUMNS a int PATH 'aux:a')

with default namespace
XMLTABLE(NAMESPACES(DEFAULT 'http://x.y&#39;),
'/rows/row' PASSING ...
COLUMNS a int);

Unfortunately the libxml2 doesn't support default namespaces in XPath
expressions. Because the libxml2 functionality is frozen, there is not big
chance for support in near future. A implementation is not too hard -
although it requires simple XPath expressions state translator.

The databases with XMLTABLE implementation supports default namespace for
XPath expressions.

The patch for initial implementation is attached.

The original message is a bit less informative for those who
wants to review this but are not accustomed (like me) to this
area. I try to augment this with a bit more information. (Perhaps)

An example of this issue can be as follows.

create table t1 (id int, doc xml);
insert into t1
values
(1, '<rows xmlns="http://x.y&quot;&gt;&lt;row&gt;&lt;a&gt;10&lt;/a&gt;&lt;/row&gt;&lt;/rows&gt;&#39;),
(2, '<rows xmlns="http://x.y&quot;&gt;&lt;row&gt;&lt;a&gt;20&lt;/a&gt;&lt;/row&gt;&lt;/rows&gt;&#39;),
(3, '<rows xmlns="http://x.y&quot;&gt;&lt;row&gt;&lt;a&gt;30&lt;/a&gt;&lt;/row&gt;&lt;/rows&gt;&#39;),
(4, '<rows xmlns="http://x.y&quot;&gt;&lt;row&gt;&lt;a&gt;40&lt;/a&gt;&lt;/row&gt;&lt;/rows&gt;&#39;);
select x.* from t1, xmltable('/rows/row' passing t1.doc columns data int PATH 'a') as x;
| data
| ------
| (0 rows)
select x.* from t1, xmltable(XMLNAMESPACES('http://x.y&#39; as n), '/n:rows/n:row' passing t1.doc columns data int PATH 'n:a') as x;
| data
| ------
| 10
| 20
| 30
| 40
| (4 rows)

But, currently the follwing command fails with error.

select x.* from t1, xmltable(XMLNAMESPACES(DEFAULT 'http://x.y&#39;), '/rows/row' passing t1.doc columns data int PATH 'a') as x;
| ERROR: DEFAULT namespace is not supported

This patch let PostgreSQL allow this syntax by transforming xpath
string when DEFAULT namespace is defined.

=======================
I have some review comments.

This patch still applies with shifts and works as expected.

1. Uniformity among simliar features

As mentioned in the proposal, but it is lack of uniformity that
the xpath transformer is applied only to xmltable and not for
other xpath related functions.

2. XML comformance

I'm not yet sure this works for the all extent of the
available syntax but at least fails for the following
expression.

(delete from t1;)
insert into t1
values
(5, '<rows xmlns="http://x.y&quot;&gt;&lt;row&gt;&lt;a hoge="haha">50</a></row></rows>');

select x.* from t1, xmltable(XMLNAMESPACES(DEFAULT 'http://x.y&#39;), '/rows/row' passing t1.doc columns data int PATH 'a[1][@hoge]') as x;

data
------

(1 row)

The following expression works.

select x.* from t1, xmltable(XMLNAMESPACES('http://x.y&#39; as x), '/x:rows/x:row' passing t1.doc columns data int PATH 'x:a[1][@hoge]') as x;

data
------
50
(1 row)

The w3c says as follows.

https://www.w3.org/TR/xml-names/#defaulting

The namespace name for an unprefixed attribute name always has no value.

We currently don't have a means to make sure that this works
correctly for the whole extent. More regression test helps?

3. The predefined prefix for default namespace

The patch defines the name of the defaut namespace as
"pgdefnamespace". If a default namespace is defined, a
namespace is made with the name and with_default_ns is true. If
a namespace with the name is defined, a namespace is made also
with the same name but with_default_ns is false. This causes a
confused behavior.

select x.* from t1, xmltable(XMLNAMESPACES(DEFAULT 'http://x.x&#39;, 'http://x.y&#39; as pgdefnamespace), '/rows/row' passing t1.doc columns data int PATH 'a') as x;
| data
| ------
| 10
| 20
| 30
| 40
| (4 rows)

The reason for the design is the fact that xmlXPathRegisterNs
doesn't accept NULL or empty string as a namespace prefix and it
only accepts a string consists of valid XML caharacters.

Even if we are to live with such restriction and such name is
hardly used, a namespace prefix with the name should be
rejected.

4. A mistake in the documentaion ?

The documentaion says about the XMLNAMESPACES clause as the
folows.

https://www.postgresql.org/docs/10/static/functions-xml.html

The optional XMLNAMESPACES clause is a comma-separated list of
namespaces. It specifies the XML namespaces used in the document
and their aliases.

As far as looking into XmlTableSetNamespace, (and if I read the
documentation correctly) the defined namespaces are not applied
on documents, but expressions. This patch is not to blame for
this. So this will be another patch backbatchable to Pg10.

| The optional XMLNAMESPACES clause is a comma-separated list of
| namespaces. It specifies the XML namespaces used in the
| row_expression.

regards,

--
Kyotaro Horiguchi
NTT Open Source Software Center

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

#3Pavel Stehule
pavel.stehule@gmail.com
In reply to: Kyotaro Horiguchi (#2)
Re: proposal - Default namespaces for XPath expressions (PostgreSQL 11)

Hi

2017-09-25 13:25 GMT+02:00 Kyotaro HORIGUCHI <
horiguchi.kyotaro@lab.ntt.co.jp>:

Hello, this patch have been ignored for a long time since its proposal...

At Sat, 11 Mar 2017 20:44:31 +0100, Pavel Stehule <pavel.stehule@gmail.com>
wrote in <CAFj8pRB+WDyDcZyGmfRdJ0HOoXugeaL-KNFeK9YA5Z10JN9qfA@mail.gmail.
com>

Hi

This proposal is followup of implementation of XMLTABLE.

Lot of XML documents has assigned document namespace.

<rows xmlns="http://x.y&quot;&gt;&lt;row&gt;&lt;a&gt;10&lt;/a&gt;&lt;/row&gt;&lt;/rows&gt;

For these XML document any search path must use schema "http://x.y&quot;.

This

is not too intuitive, and from XMLTABLE usage is not too user friendly,
because the default column path (same like column name) cannot be used. A
solution of this issue is default namespace - defined in SQL/XML.

example - related to previous xml

without default namespace:
XMLTABLE(NAMESPACES('http://x.y&#39; AS aux),
'/aux:rows/aux:row' PASSING ...
COLUMNS a int PATH 'aux:a')

with default namespace
XMLTABLE(NAMESPACES(DEFAULT 'http://x.y&#39;),
'/rows/row' PASSING ...
COLUMNS a int);

Unfortunately the libxml2 doesn't support default namespaces in XPath
expressions. Because the libxml2 functionality is frozen, there is not

big

chance for support in near future. A implementation is not too hard -
although it requires simple XPath expressions state translator.

The databases with XMLTABLE implementation supports default namespace for
XPath expressions.

The patch for initial implementation is attached.

The original message is a bit less informative for those who
wants to review this but are not accustomed (like me) to this
area. I try to augment this with a bit more information. (Perhaps)

An example of this issue can be as follows.

create table t1 (id int, doc xml);
insert into t1
values
(1, '<rows xmlns="http://x.y&quot;&gt;&lt;row&gt;&lt;a&gt;10&lt;/a&gt;&lt;/row&gt;&lt;/rows&gt;&#39;),
(2, '<rows xmlns="http://x.y&quot;&gt;&lt;row&gt;&lt;a&gt;20&lt;/a&gt;&lt;/row&gt;&lt;/rows&gt;&#39;),
(3, '<rows xmlns="http://x.y&quot;&gt;&lt;row&gt;&lt;a&gt;30&lt;/a&gt;&lt;/row&gt;&lt;/rows&gt;&#39;),
(4, '<rows xmlns="http://x.y&quot;&gt;&lt;row&gt;&lt;a&gt;40&lt;/a&gt;&lt;/row&gt;&lt;/rows&gt;&#39;);
select x.* from t1, xmltable('/rows/row' passing t1.doc columns data int
PATH 'a') as x;
| data
| ------
| (0 rows)
select x.* from t1, xmltable(XMLNAMESPACES('http://x.y&#39; as n),
'/n:rows/n:row' passing t1.doc columns data int PATH 'n:a') as x;
| data
| ------
| 10
| 20
| 30
| 40
| (4 rows)

But, currently the follwing command fails with error.

select x.* from t1, xmltable(XMLNAMESPACES(DEFAULT 'http://x.y&#39;),
'/rows/row' passing t1.doc columns data int PATH 'a') as x;
| ERROR: DEFAULT namespace is not supported

This patch let PostgreSQL allow this syntax by transforming xpath
string when DEFAULT namespace is defined.

=======================
I have some review comments.

This patch still applies with shifts and works as expected.

1. Uniformity among simliar features

As mentioned in the proposal, but it is lack of uniformity that
the xpath transformer is applied only to xmltable and not for
other xpath related functions.

I have to fix the XPath function. The SQL/XML function Xmlexists doesn't
support namespaces/

2. XML comformance

I'm not yet sure this works for the all extent of the
available syntax but at least fails for the following
expression.

(delete from t1;)
insert into t1
values
(5, '<rows xmlns="http://x.y&quot;&gt;&lt;row&gt;&lt;a hoge="haha">50</a></row></
rows>');

select x.* from t1, xmltable(XMLNAMESPACES(DEFAULT 'http://x.y&#39;),
'/rows/row' passing t1.doc columns data int PATH 'a[1][@hoge]') as x;

data
------

(1 row)

The following expression works.

select x.* from t1, xmltable(XMLNAMESPACES('http://x.y&#39; as x),
'/x:rows/x:row' passing t1.doc columns data int PATH 'x:a[1][@hoge]') as x;

data
------
50
(1 row)

The w3c says as follows.

https://www.w3.org/TR/xml-names/#defaulting

The namespace name for an unprefixed attribute name always has no

value.

We currently don't have a means to make sure that this works
correctly for the whole extent. More regression test helps?

I fixed this issue and I used your examples as regression tests

3. The predefined prefix for default namespace

The patch defines the name of the defaut namespace as
"pgdefnamespace". If a default namespace is defined, a
namespace is made with the name and with_default_ns is true. If
a namespace with the name is defined, a namespace is made also
with the same name but with_default_ns is false. This causes a
confused behavior.

select x.* from t1, xmltable(XMLNAMESPACES(DEFAULT 'http://x.x&#39;, '
http://x.y&#39; as pgdefnamespace), '/rows/row' passing t1.doc columns data
int PATH 'a') as x;
| data
| ------
| 10
| 20
| 30
| 40
| (4 rows)

The reason for the design is the fact that xmlXPathRegisterNs
doesn't accept NULL or empty string as a namespace prefix and it
only accepts a string consists of valid XML caharacters.

Even if we are to live with such restriction and such name is
hardly used, a namespace prefix with the name should be
rejected.

it is fixed - look to regress test

4. A mistake in the documentaion ?

The documentaion says about the XMLNAMESPACES clause as the
folows.

https://www.postgresql.org/docs/10/static/functions-xml.html

The optional XMLNAMESPACES clause is a comma-separated list of
namespaces. It specifies the XML namespaces used in the document
and their aliases.

As far as looking into XmlTableSetNamespace, (and if I read the
documentation correctly) the defined namespaces are not applied
on documents, but expressions. This patch is not to blame for
this. So this will be another patch backbatchable to Pg10.

| The optional XMLNAMESPACES clause is a comma-separated list of
| namespaces. It specifies the XML namespaces used in the
| row_expression.

Regards

Pavel

Show quoted text

regards,

--
Kyotaro Horiguchi
NTT Open Source Software Center

Attachments:

xml-xpath-default-ns-2.patchtext/x-patch; charset=US-ASCII; name=xml-xpath-default-ns-2.patchDownload+401-9
#4Pavel Stehule
pavel.stehule@gmail.com
In reply to: Pavel Stehule (#3)
Re: proposal - Default namespaces for XPath expressions (PostgreSQL 11)

Hi

now xpath and xpath_exists supports default namespace too

updated doc,
fixed all variants of expected result test file

Regards

Pavel

Attachments:

xml-xpath-default-ns-3.patchtext/x-patch; charset=US-ASCII; name=xml-xpath-default-ns-3.patchDownload+582-14
#5Kyotaro Horiguchi
horikyota.ntt@gmail.com
In reply to: Kyotaro Horiguchi (#2)
Re: proposal - Default namespaces for XPath expressions (PostgreSQL 11)

Hi, thanks for the new patch.

# The patch is missing xpath_parser.h. That of the first patch was usable.

At Thu, 28 Sep 2017 07:59:41 +0200, Pavel Stehule <pavel.stehule@gmail.com> wrote in <CAFj8pRBMQa07a=+qQAVMtz5M_hqkJBhiQSOP76+-BrFDj37pvg@mail.gmail.com>

Hi

now xpath and xpath_exists supports default namespace too

At Wed, 27 Sep 2017 22:41:52 +0200, Pavel Stehule <pavel.stehule@gmail.com> wrote in <CAFj8pRCZ8oneG7g2vxs9ux71n8A9twwUO7zQpJiuz+7RGSpSuw@mail.gmail.com>

1. Uniformity among simliar features

As mentioned in the proposal, but it is lack of uniformity that
the xpath transformer is applied only to xmltable and not for
other xpath related functions.

I have to fix the XPath function. The SQL/XML function Xmlexists doesn't
support namespaces/

Sorry, I forgot to care about that. (And the definition of
namespace array is of course fabricated by me). I'd like to leave
this to committers. Anyway it is working but the syntax (or
whether it is acceptable) is still arguable.

SELECT xpath('/a/text()', '<my:a xmlns:my="http://example.com&quot;&gt;test&lt;/my:a&gt;&#39;,
ARRAY[ARRAY['', 'http://example.com&#39;]]);
| xpath
| --------
| {test}
| (1 row)

The internal name is properly rejected, but the current internal
name (pgdefnamespace.pgsqlxml.internal) seems a bit too long. We
are preserving some short names and reject them as
user-defined. Doesn't just 'pgsqlxml' work?

Default namespace correctly become to be applied on bare
attribute names.

updated doc,
fixed all variants of expected result test file

Sorry for one by one comment but I found another misbehavior.

create table t1 (id int, doc xml);
insert into t1
values
(5, '<rows xmlns="http://x.y&quot;&gt;&lt;row&gt;&lt;a hoge="haha">50</a></row></rows>');
select x.* from t1, xmltable(XMLNAMESPACES('http://x.y&#39; AS x), '/x:rows/x:row' passing t1.doc columns data int PATH 'child::x:a[1][attribute::hoge="haha"]') as x;
| data
| ------
| 50

but the following fails.

select x.* from t1, xmltable(XMLNAMESPACES(DEFAULT 'http://x.y&#39;), '/rows/row' passing t1.doc columns data int PATH 'child::a[1][attribute::hoge="haha"]') as x;
| data
| ------
|
| (1 row)

Perhaps child::a is not prefixed by the transformation.

XPath might be complex enough so that it's worth switching to
yacc/lex based transformer that is formally verifiable and won't
need a bunch of cryptic tests that finally cannot prove the
completeness. synchronous_standy_names is far simpler than XPath
but using yacc/lex parser.

Anyway the following is nitpicking of the current xpath_parser.c.

- NODENAME_FIRSTCHAR allows '-' as the first char but it is
excluded from NameStartChar (https://www.w3.org/TR/REC-xml/#NT-NameStartChar)
I think characters with high-bit set is okay.
Also IS_NODENAME_CHAR should be changed.

- NODENAME_FIRSTCHAR and IS_NODENAME_CHAR is in the same category
but have different naming schemes. Can these are named in the same way?

- The current transoformer seems to using up to one token stack
depth. Maybe the stack is needless. (pushed token is always
popped just after)

regards,

--
Kyotaro Horiguchi
NTT Open Source Software Center

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

#6Pavel Stehule
pavel.stehule@gmail.com
In reply to: Kyotaro Horiguchi (#5)
Re: proposal - Default namespaces for XPath expressions (PostgreSQL 11)

2017-10-02 12:22 GMT+02:00 Kyotaro HORIGUCHI <
horiguchi.kyotaro@lab.ntt.co.jp>:

Hi, thanks for the new patch.

# The patch is missing xpath_parser.h. That of the first patch was usable.

At Thu, 28 Sep 2017 07:59:41 +0200, Pavel Stehule <pavel.stehule@gmail.com>
wrote in <CAFj8pRBMQa07a=+qQAVMtz5M_hqkJBhiQSOP76+-BrFDj37pvg@
mail.gmail.com>

Hi

now xpath and xpath_exists supports default namespace too

At Wed, 27 Sep 2017 22:41:52 +0200, Pavel Stehule <pavel.stehule@gmail.com>
wrote in <CAFj8pRCZ8oneG7g2vxs9ux71n8A9twwUO7zQpJiuz+7RGSpSuw@mail.
gmail.com>

1. Uniformity among simliar features

As mentioned in the proposal, but it is lack of uniformity that
the xpath transformer is applied only to xmltable and not for
other xpath related functions.

I have to fix the XPath function. The SQL/XML function Xmlexists doesn't
support namespaces/

Sorry, I forgot to care about that. (And the definition of
namespace array is of course fabricated by me). I'd like to leave
this to committers. Anyway it is working but the syntax (or
whether it is acceptable) is still arguable.

SELECT xpath('/a/text()', '<my:a xmlns:my="http://example.com&quot;&gt;
test</my:a>',
ARRAY[ARRAY['', 'http://example.com&#39;]]);
| xpath
| --------
| {test}
| (1 row)

The internal name is properly rejected, but the current internal
name (pgdefnamespace.pgsqlxml.internal) seems a bit too long. We
are preserving some short names and reject them as
user-defined. Doesn't just 'pgsqlxml' work?

LibXML2 does trim to 100 bytes length names. So
pgdefnamespace.pgsqlxml.internal
is safe from this perspective.

I would to decraese a risk of possible collision, so longer string is
better. Maybe "pgsqlxml.internal" is good enoug - I have not a idea. But if
somewhere will be this string printed, then
"pgdefnamespace.pgsqlxml.internal" has clean semantic, and it is reason,
why I prefer this string. PostgreSQL uses 63 bytes names - and this string
is correct too.

Default namespace correctly become to be applied on bare
attribute names.

updated doc,
fixed all variants of expected result test file

Sorry for one by one comment but I found another misbehavior.

create table t1 (id int, doc xml);
insert into t1
values
(5, '<rows xmlns="http://x.y&quot;&gt;&lt;row&gt;&lt;a hoge="haha">50</a></row></
rows>');
select x.* from t1, xmltable(XMLNAMESPACES('http://x.y&#39; AS x),
'/x:rows/x:row' passing t1.doc columns data int PATH
'child::x:a[1][attribute::hoge="haha"]') as x;
| data
| ------
| 50

but the following fails.

select x.* from t1, xmltable(XMLNAMESPACES(DEFAULT 'http://x.y&#39;),
'/rows/row' passing t1.doc columns data int PATH
'child::a[1][attribute::hoge="haha"]') as x;
| data
| ------
|
| (1 row)

Perhaps child::a is not prefixed by the transformation.

XPath might be complex enough so that it's worth switching to
yacc/lex based transformer that is formally verifiable and won't
need a bunch of cryptic tests that finally cannot prove the
completeness. synchronous_standy_names is far simpler than XPath
but using yacc/lex parser.

I don't think (not yet) - it is simple state machine now, and when the code
will be stable, then will not be modified.

Thank you for comments, I'll look on it

Regards

Pavel

Show quoted text

Anyway the following is nitpicking of the current xpath_parser.c.

- NODENAME_FIRSTCHAR allows '-' as the first char but it is
excluded from NameStartChar (https://www.w3.org/TR/REC-
xml/#NT-NameStartChar)
I think characters with high-bit set is okay.
Also IS_NODENAME_CHAR should be changed.

- NODENAME_FIRSTCHAR and IS_NODENAME_CHAR is in the same category
but have different naming schemes. Can these are named in the same way?

- The current transoformer seems to using up to one token stack
depth. Maybe the stack is needless. (pushed token is always
popped just after)

regards,

--
Kyotaro Horiguchi
NTT Open Source Software Center

#7Kyotaro Horiguchi
horikyota.ntt@gmail.com
In reply to: Pavel Stehule (#6)
Re: proposal - Default namespaces for XPath expressions (PostgreSQL 11)

At Mon, 2 Oct 2017 12:43:19 +0200, Pavel Stehule <pavel.stehule@gmail.com> wrote in <CAFj8pRCD8=AzbRJQ2_2rp3+uzade9GHbm0DAF3-t__yVtzo2cA@mail.gmail.com>

Sorry, I forgot to care about that. (And the definition of
namespace array is of course fabricated by me). I'd like to leave
this to committers. Anyway it is working but the syntax (or
whether it is acceptable) is still arguable.

SELECT xpath('/a/text()', '<my:a xmlns:my="http://example.com&quot;&gt;
test</my:a>',
ARRAY[ARRAY['', 'http://example.com&#39;]]);
| xpath
| --------
| {test}
| (1 row)

The internal name is properly rejected, but the current internal
name (pgdefnamespace.pgsqlxml.internal) seems a bit too long. We
are preserving some short names and reject them as
user-defined. Doesn't just 'pgsqlxml' work?

LibXML2 does trim to 100 bytes length names. So
pgdefnamespace.pgsqlxml.internal
is safe from this perspective.

I would to decraese a risk of possible collision, so longer string is
better. Maybe "pgsqlxml.internal" is good enoug - I have not a idea. But if
somewhere will be this string printed, then
"pgdefnamespace.pgsqlxml.internal" has clean semantic, and it is reason,
why I prefer this string. PostgreSQL uses 63 bytes names - and this string
is correct too.

Ok, I'm fine with that.

Default namespace correctly become to be applied on bare
attribute names.

updated doc,
fixed all variants of expected result test file

Sorry for one by one comment but I found another misbehavior.

create table t1 (id int, doc xml);
insert into t1
values
(5, '<rows xmlns="http://x.y&quot;&gt;&lt;row&gt;&lt;a hoge="haha">50</a></row></
rows>');
select x.* from t1, xmltable(XMLNAMESPACES('http://x.y&#39; AS x),
'/x:rows/x:row' passing t1.doc columns data int PATH
'child::x:a[1][attribute::hoge="haha"]') as x;
| data
| ------
| 50

but the following fails.

select x.* from t1, xmltable(XMLNAMESPACES(DEFAULT 'http://x.y&#39;),
'/rows/row' passing t1.doc columns data int PATH
'child::a[1][attribute::hoge="haha"]') as x;
| data
| ------
|
| (1 row)

Perhaps child::a is not prefixed by the transformation.

XPath might be complex enough so that it's worth switching to
yacc/lex based transformer that is formally verifiable and won't
need a bunch of cryptic tests that finally cannot prove the
completeness. synchronous_standy_names is far simpler than XPath
but using yacc/lex parser.

I don't think (not yet) - it is simple state machine now, and when the code
will be stable, then will not be modified.

Hmm. Ok, agreed. I didn't mean the current shape ought to be
changed.

Thank you for comments, I'll look on it

regards,

--
Kyotaro Horiguchi
NTT Open Source Software Center

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

#8Pavel Stehule
pavel.stehule@gmail.com
In reply to: Kyotaro Horiguchi (#5)
Re: proposal - Default namespaces for XPath expressions (PostgreSQL 11)

2017-10-02 12:22 GMT+02:00 Kyotaro HORIGUCHI <
horiguchi.kyotaro@lab.ntt.co.jp>:

Hi, thanks for the new patch.

# The patch is missing xpath_parser.h. That of the first patch was usable.

At Thu, 28 Sep 2017 07:59:41 +0200, Pavel Stehule <pavel.stehule@gmail.com>
wrote in <CAFj8pRBMQa07a=+qQAVMtz5M_hqkJBhiQSOP76+-BrFDj37pvg@
mail.gmail.com>

Hi

now xpath and xpath_exists supports default namespace too

At Wed, 27 Sep 2017 22:41:52 +0200, Pavel Stehule <pavel.stehule@gmail.com>
wrote in <CAFj8pRCZ8oneG7g2vxs9ux71n8A9twwUO7zQpJiuz+7RGSpSuw@mail.
gmail.com>

1. Uniformity among simliar features

As mentioned in the proposal, but it is lack of uniformity that
the xpath transformer is applied only to xmltable and not for
other xpath related functions.

I have to fix the XPath function. The SQL/XML function Xmlexists doesn't
support namespaces/

Sorry, I forgot to care about that. (And the definition of
namespace array is of course fabricated by me). I'd like to leave
this to committers. Anyway it is working but the syntax (or
whether it is acceptable) is still arguable.

SELECT xpath('/a/text()', '<my:a xmlns:my="http://example.com&quot;&gt;
test</my:a>',
ARRAY[ARRAY['', 'http://example.com&#39;]]);
| xpath
| --------
| {test}
| (1 row)

The internal name is properly rejected, but the current internal
name (pgdefnamespace.pgsqlxml.internal) seems a bit too long. We
are preserving some short names and reject them as
user-defined. Doesn't just 'pgsqlxml' work?

Default namespace correctly become to be applied on bare
attribute names.

updated doc,
fixed all variants of expected result test file

Sorry for one by one comment but I found another misbehavior.

create table t1 (id int, doc xml);
insert into t1
values
(5, '<rows xmlns="http://x.y&quot;&gt;&lt;row&gt;&lt;a hoge="haha">50</a></row></
rows>');
select x.* from t1, xmltable(XMLNAMESPACES('http://x.y&#39; AS x),
'/x:rows/x:row' passing t1.doc columns data int PATH
'child::x:a[1][attribute::hoge="haha"]') as x;
| data
| ------
| 50

but the following fails.

select x.* from t1, xmltable(XMLNAMESPACES(DEFAULT 'http://x.y&#39;),
'/rows/row' passing t1.doc columns data int PATH
'child::a[1][attribute::hoge="haha"]') as x;
| data
| ------
|
| (1 row)

Perhaps child::a is not prefixed by the transformation.

the problem was in unwanted attribute modification. The parser didn't
detect "attribute::hoge" as attribute. Updated parser does it. I reduce
duplicated code there more.

XPath might be complex enough so that it's worth switching to
yacc/lex based transformer that is formally verifiable and won't
need a bunch of cryptic tests that finally cannot prove the
completeness. synchronous_standy_names is far simpler than XPath
but using yacc/lex parser.

Anyway the following is nitpicking of the current xpath_parser.c.

- NODENAME_FIRSTCHAR allows '-' as the first char but it is
excluded from NameStartChar (https://www.w3.org/TR/REC-
xml/#NT-NameStartChar)
I think characters with high-bit set is okay.
Also IS_NODENAME_CHAR should be changed.

fixed

- NODENAME_FIRSTCHAR and IS_NODENAME_CHAR is in the same category
but have different naming schemes. Can these are named in the same way?

fixed

- The current transoformer seems to using up to one token stack
depth. Maybe the stack is needless. (pushed token is always
popped just after)

fixed

Regards

Pavel

Show quoted text

regards,

--
Kyotaro Horiguchi
NTT Open Source Software Center

Attachments:

xml-xpath-default-ns-4.patchtext/x-patch; charset=US-ASCII; name=xml-xpath-default-ns-4.patchDownload+594-14
#9Kyotaro Horiguchi
horikyota.ntt@gmail.com
In reply to: Pavel Stehule (#8)
Re: proposal - Default namespaces for XPath expressions (PostgreSQL 11)

Thank you for the new patch.

- The latest patch is missing xpath_parser.h at least since
ns-3. That of the first (not-numbered) version was still
usable.

- c29c578 conflicts on doc/src/sgml/func.sgml

At Sun, 15 Oct 2017 12:06:11 +0200, Pavel Stehule <pavel.stehule@gmail.com> wrote in <CAFj8pRCYBH+a6oJoEYUFDUpBQ1ySwtt2CfnFZxs2Ab9EfONbUQ@mail.gmail.com>

2017-10-02 12:22 GMT+02:00 Kyotaro HORIGUCHI <
horiguchi.kyotaro@lab.ntt.co.jp>:

Hi, thanks for the new patch.

# The patch is missing xpath_parser.h. That of the first patch was usable.

At Thu, 28 Sep 2017 07:59:41 +0200, Pavel Stehule <pavel.stehule@gmail.com>
wrote in <CAFj8pRBMQa07a=+qQAVMtz5M_hqkJBhiQSOP76+-BrFDj37pvg@
mail.gmail.com>

Hi

now xpath and xpath_exists supports default namespace too

At Wed, 27 Sep 2017 22:41:52 +0200, Pavel Stehule <pavel.stehule@gmail.com>
wrote in <CAFj8pRCZ8oneG7g2vxs9ux71n8A9twwUO7zQpJiuz+7RGSpSuw@mail.
gmail.com>

1. Uniformity among simliar features

As mentioned in the proposal, but it is lack of uniformity that
the xpath transformer is applied only to xmltable and not for
other xpath related functions.

I have to fix the XPath function. The SQL/XML function Xmlexists doesn't
support namespaces/

Sorry, I forgot to care about that. (And the definition of
namespace array is of course fabricated by me). I'd like to leave
this to committers. Anyway it is working but the syntax (or
whether it is acceptable) is still arguable.

SELECT xpath('/a/text()', '<my:a xmlns:my="http://example.com&quot;&gt;
test</my:a>',
ARRAY[ARRAY['', 'http://example.com&#39;]]);
| xpath
| --------
| {test}
| (1 row)

The internal name is properly rejected, but the current internal
name (pgdefnamespace.pgsqlxml.internal) seems a bit too long. We
are preserving some short names and reject them as
user-defined. Doesn't just 'pgsqlxml' work?

Default namespace correctly become to be applied on bare
attribute names.

updated doc,
fixed all variants of expected result test file

Sorry for one by one comment but I found another misbehavior.

create table t1 (id int, doc xml);
insert into t1
values
(5, '<rows xmlns="http://x.y&quot;&gt;&lt;row&gt;&lt;a hoge="haha">50</a></row></
rows>');
select x.* from t1, xmltable(XMLNAMESPACES('http://x.y&#39; AS x),
'/x:rows/x:row' passing t1.doc columns data int PATH
'child::x:a[1][attribute::hoge="haha"]') as x;
| data
| ------
| 50

but the following fails.

select x.* from t1, xmltable(XMLNAMESPACES(DEFAULT 'http://x.y&#39;),
'/rows/row' passing t1.doc columns data int PATH
'child::a[1][attribute::hoge="haha"]') as x;
| data
| ------
|
| (1 row)

Perhaps child::a is not prefixed by the transformation.

the problem was in unwanted attribute modification. The parser didn't
detect "attribute::hoge" as attribute. Updated parser does it. I reduce
duplicated code there more.

It worked as expected. But the comparison of "attribute" is
missing t1.length = 9 so the following expression wrongly passes.

child::a[1][attributeabcdefg::hoge="haha"

It is confusing that is_qual_name becomes true when t2 is not a
"qual name", and the way it treats a double-colon is hard to
understand.

It essentially does inserting the default namespace before
unqualified non-attribute name. I believe we can easily
look-ahead to detect a double colon and it would make things
simpler. Could you consider something like the attached patch?
(applies on top of ns-4 patch.)

XPath might be complex enough so that it's worth switching to
yacc/lex based transformer that is formally verifiable and won't
need a bunch of cryptic tests that finally cannot prove the
completeness. synchronous_standy_names is far simpler than XPath
but using yacc/lex parser.

Anyway the following is nitpicking of the current xpath_parser.c.

- NODENAME_FIRSTCHAR allows '-' as the first char but it is
excluded from NameStartChar (https://www.w3.org/TR/REC-
xml/#NT-NameStartChar)
I think characters with high-bit set is okay.
Also IS_NODENAME_CHAR should be changed.

fixed

- NODENAME_FIRSTCHAR and IS_NODENAME_CHAR is in the same category
but have different naming schemes. Can these are named in the same way?

fixed

- The current transoformer seems to using up to one token stack
depth. Maybe the stack is needless. (pushed token is always
popped just after)

fixed

Thank you.

I found another (and should be the last, so sorry..) functional
defect in this. This doesn't add default namespace if the tag
name in a predicate is 'and' or 'or'. It needs to be fixed, or
wrote in the documentation as a restriction. (seem hard to fix
it..)

create table t1 (id int, doc xml);
insert into t1 values (1, '<rows xmlns="http://x.y&quot;&gt;&lt;row&gt;&lt;val&gt;50&lt;/val&gt;&lt;and&gt;60&lt;/and&gt;&lt;/row&gt;&lt;/rows&gt;&#39;);
select x.* from t1, xmltable(XMLNAMESPACES('http://x.y&#39; AS x),
'/x:rows/x:row' passing t1.doc columns data int PATH
'x:val[../x:and = 60]') as x;
data
------
50
(1 row)
select x.* from t1, xmltable(XMLNAMESPACES(DEFAULT 'http://x.y&#39;),
'/rows/row' passing t1.doc columns data int PATH
'val[../and = 60]') as x;
data
------

(1 row)

Other comments are follows.

- Please add more comments. XPATH_TOKEN_NAME in _transformXPath
in my patch has more

- Debug output might be needed.

# sorry now time's up. will continue tomorrow.

regards,

--
Kyotaro Horiguchi
NTT Open Source Software Center

Attachments:

xml-xpath-default-ns-4-kh.patchtext/x-patch; charset=us-asciiDownload+67-41
#10Pavel Stehule
pavel.stehule@gmail.com
In reply to: Kyotaro Horiguchi (#9)
Re: proposal - Default namespaces for XPath expressions (PostgreSQL 11)

Hi

2017-11-06 14:00 GMT+01:00 Kyotaro HORIGUCHI <
horiguchi.kyotaro@lab.ntt.co.jp>:

Thank you for the new patch.

- The latest patch is missing xpath_parser.h at least since
ns-3. That of the first (not-numbered) version was still
usable.

- c29c578 conflicts on doc/src/sgml/func.sgml

At Sun, 15 Oct 2017 12:06:11 +0200, Pavel Stehule <pavel.stehule@gmail.com>
wrote in <CAFj8pRCYBH+a6oJoEYUFDUpBQ1ySwtt2CfnFZxs2A
b9EfONbUQ@mail.gmail.com>

2017-10-02 12:22 GMT+02:00 Kyotaro HORIGUCHI <
horiguchi.kyotaro@lab.ntt.co.jp>:

Hi, thanks for the new patch.

# The patch is missing xpath_parser.h. That of the first patch was

usable.

At Thu, 28 Sep 2017 07:59:41 +0200, Pavel Stehule <

pavel.stehule@gmail.com>

wrote in <CAFj8pRBMQa07a=+qQAVMtz5M_hqkJBhiQSOP76+-BrFDj37pvg@
mail.gmail.com>

Hi

now xpath and xpath_exists supports default namespace too

At Wed, 27 Sep 2017 22:41:52 +0200, Pavel Stehule <

pavel.stehule@gmail.com>

wrote in <CAFj8pRCZ8oneG7g2vxs9ux71n8A9twwUO7zQpJiuz+7RGSpSuw@mail.
gmail.com>

1. Uniformity among simliar features

As mentioned in the proposal, but it is lack of uniformity that
the xpath transformer is applied only to xmltable and not for
other xpath related functions.

I have to fix the XPath function. The SQL/XML function Xmlexists

doesn't

support namespaces/

Sorry, I forgot to care about that. (And the definition of
namespace array is of course fabricated by me). I'd like to leave
this to committers. Anyway it is working but the syntax (or
whether it is acceptable) is still arguable.

SELECT xpath('/a/text()', '<my:a xmlns:my="http://example.com&quot;&gt;
test</my:a>',
ARRAY[ARRAY['', 'http://example.com&#39;]]);
| xpath
| --------
| {test}
| (1 row)

The internal name is properly rejected, but the current internal
name (pgdefnamespace.pgsqlxml.internal) seems a bit too long. We
are preserving some short names and reject them as
user-defined. Doesn't just 'pgsqlxml' work?

Default namespace correctly become to be applied on bare
attribute names.

updated doc,
fixed all variants of expected result test file

Sorry for one by one comment but I found another misbehavior.

create table t1 (id int, doc xml);
insert into t1
values
(5, '<rows xmlns="http://x.y&quot;&gt;&lt;row&gt;&lt;a hoge="haha">50</a></row></
rows>');
select x.* from t1, xmltable(XMLNAMESPACES('http://x.y&#39; AS x),
'/x:rows/x:row' passing t1.doc columns data int PATH
'child::x:a[1][attribute::hoge="haha"]') as x;
| data
| ------
| 50

but the following fails.

select x.* from t1, xmltable(XMLNAMESPACES(DEFAULT 'http://x.y&#39;),
'/rows/row' passing t1.doc columns data int PATH
'child::a[1][attribute::hoge="haha"]') as x;
| data
| ------
|
| (1 row)

Perhaps child::a is not prefixed by the transformation.

the problem was in unwanted attribute modification. The parser didn't
detect "attribute::hoge" as attribute. Updated parser does it. I reduce
duplicated code there more.

It worked as expected. But the comparison of "attribute" is
missing t1.length = 9 so the following expression wrongly passes.

child::a[1][attributeabcdefg::hoge="haha"

It is confusing that is_qual_name becomes true when t2 is not a
"qual name", and the way it treats a double-colon is hard to
understand.

It essentially does inserting the default namespace before
unqualified non-attribute name. I believe we can easily
look-ahead to detect a double colon and it would make things
simpler. Could you consider something like the attached patch?
(applies on top of ns-4 patch.)

XPath might be complex enough so that it's worth switching to
yacc/lex based transformer that is formally verifiable and won't
need a bunch of cryptic tests that finally cannot prove the
completeness. synchronous_standy_names is far simpler than XPath
but using yacc/lex parser.

Anyway the following is nitpicking of the current xpath_parser.c.

- NODENAME_FIRSTCHAR allows '-' as the first char but it is
excluded from NameStartChar (https://www.w3.org/TR/REC-
xml/#NT-NameStartChar)
I think characters with high-bit set is okay.
Also IS_NODENAME_CHAR should be changed.

fixed

- NODENAME_FIRSTCHAR and IS_NODENAME_CHAR is in the same category
but have different naming schemes. Can these are named in the same

way?

fixed

- The current transoformer seems to using up to one token stack
depth. Maybe the stack is needless. (pushed token is always
popped just after)

fixed

Thank you.

I found another (and should be the last, so sorry..) functional
defect in this. This doesn't add default namespace if the tag
name in a predicate is 'and' or 'or'. It needs to be fixed, or
wrote in the documentation as a restriction. (seem hard to fix
it..)

create table t1 (id int, doc xml);
insert into t1 values (1, '<rows xmlns="http://x.y&quot;&gt;&lt;row&gt;&lt;val&gt;
50</val><and>60</and></row></rows>');
select x.* from t1, xmltable(XMLNAMESPACES('http://x.y&#39; AS x),
'/x:rows/x:row' passing t1.doc columns data int PATH
'x:val[../x:and = 60]') as x;
data
------
50
(1 row)
select x.* from t1, xmltable(XMLNAMESPACES(DEFAULT 'http://x.y&#39;),
'/rows/row' passing t1.doc columns data int PATH
'val[../and = 60]') as x;
data
------

(1 row)

yes - this check needs context parser. I am expecting, this case is corner
case, not too much usual, so doc based solution is enough.

Other comments are follows.

- Please add more comments. XPATH_TOKEN_NAME in _transformXPath
in my patch has more

- Debug output might be needed.

# sorry now time's up. will continue tomorrow.

I fixed I hope almost all issues - your patch is merged with some changes.
The most significant change is a reaction to broken XPath expression. I
prefer do nothing - libxml2 raise a error.

Attached new version.

Thank you for tips, ideas, code :)

Show quoted text

regards,

--
Kyotaro Horiguchi
NTT Open Source Software Center

Attachments:

xml-xpath-default-ns-5.patchtext/x-patch; charset=US-ASCII; name=xml-xpath-default-ns-5.patchDownload+660-14
#11Thomas Munro
thomas.munro@gmail.com
In reply to: Pavel Stehule (#10)
Re: [HACKERS] proposal - Default namespaces for XPath expressions (PostgreSQL 11)

On Thu, Nov 9, 2017 at 10:11 PM, Pavel Stehule <pavel.stehule@gmail.com> wrote:

Attached new version.

Hi Pavel,

FYI my patch testing robot says[1]https://travis-ci.org/postgresql-cfbot/postgresql/builds/305979133:

xml ... FAILED

regression.diffs says:

+ SELECT x.* FROM t1, xmltable(XMLNAMESPACES(DEFAULT 'http://x.y'),
'/rows/row' PASSING t1.doc COLUMNS data int PATH
'child::a[1][attribute::hoge="haha"]') as x;
+ data
+ ------
+ (0 rows)
+

Maybe you forgot to git-add the expected file?

[1]: https://travis-ci.org/postgresql-cfbot/postgresql/builds/305979133

--
Thomas Munro
http://www.enterprisedb.com

#12Pavel Stehule
pavel.stehule@gmail.com
In reply to: Thomas Munro (#11)
Re: [HACKERS] proposal - Default namespaces for XPath expressions (PostgreSQL 11)

Hi

2017-11-22 22:49 GMT+01:00 Thomas Munro <thomas.munro@enterprisedb.com>:

On Thu, Nov 9, 2017 at 10:11 PM, Pavel Stehule <pavel.stehule@gmail.com>
wrote:

Attached new version.

Hi Pavel,

FYI my patch testing robot says[1]:

xml ... FAILED

regression.diffs says:

+ SELECT x.* FROM t1, xmltable(XMLNAMESPACES(DEFAULT 'http://x.y'),
'/rows/row' PASSING t1.doc COLUMNS data int PATH
'child::a[1][attribute::hoge="haha"]') as x;
+ data
+ ------
+ (0 rows)
+

Maybe you forgot to git-add the expected file?

[1] https://travis-ci.org/postgresql-cfbot/postgresql/builds/305979133

unfortunately xml.out has 3 versions and is possible so one version should
be taken elsewhere than my comp.

please can me send your result xml.out file?

Regards

Pavel

Show quoted text

--
Thomas Munro
http://www.enterprisedb.com

#13Pavel Stehule
pavel.stehule@gmail.com
In reply to: Pavel Stehule (#12)
Re: [HACKERS] proposal - Default namespaces for XPath expressions (PostgreSQL 11)

2017-11-24 17:53 GMT+01:00 Pavel Stehule <pavel.stehule@gmail.com>:

Hi

2017-11-22 22:49 GMT+01:00 Thomas Munro <thomas.munro@enterprisedb.com>:

On Thu, Nov 9, 2017 at 10:11 PM, Pavel Stehule <pavel.stehule@gmail.com>
wrote:

Attached new version.

Hi Pavel,

FYI my patch testing robot says[1]:

xml ... FAILED

regression.diffs says:

+ SELECT x.* FROM t1, xmltable(XMLNAMESPACES(DEFAULT 'http://x.y'),
'/rows/row' PASSING t1.doc COLUMNS data int PATH
'child::a[1][attribute::hoge="haha"]') as x;
+ data
+ ------
+ (0 rows)
+

Maybe you forgot to git-add the expected file?

[1] https://travis-ci.org/postgresql-cfbot/postgresql/builds/305979133

unfortunately xml.out has 3 versions and is possible so one version should
be taken elsewhere than my comp.

please can me send your result xml.out file?

looks like this case is without xml support so I can fix on my comp.

Show quoted text

Regards

Pavel

--
Thomas Munro
http://www.enterprisedb.com

#14Pavel Stehule
pavel.stehule@gmail.com
In reply to: Pavel Stehule (#13)
Re: [HACKERS] proposal - Default namespaces for XPath expressions (PostgreSQL 11)

2017-11-24 18:13 GMT+01:00 Pavel Stehule <pavel.stehule@gmail.com>:

2017-11-24 17:53 GMT+01:00 Pavel Stehule <pavel.stehule@gmail.com>:

Hi

2017-11-22 22:49 GMT+01:00 Thomas Munro <thomas.munro@enterprisedb.com>:

On Thu, Nov 9, 2017 at 10:11 PM, Pavel Stehule <pavel.stehule@gmail.com>
wrote:

Attached new version.

Hi Pavel,

FYI my patch testing robot says[1]:

xml ... FAILED

regression.diffs says:

+ SELECT x.* FROM t1, xmltable(XMLNAMESPACES(DEFAULT 'http://x.y'),
'/rows/row' PASSING t1.doc COLUMNS data int PATH
'child::a[1][attribute::hoge="haha"]') as x;
+ data
+ ------
+ (0 rows)
+

Maybe you forgot to git-add the expected file?

[1] https://travis-ci.org/postgresql-cfbot/postgresql/builds/305979133

unfortunately xml.out has 3 versions and is possible so one version
should be taken elsewhere than my comp.

please can me send your result xml.out file?

looks like this case is without xml support so I can fix on my comp.

fixed regress test

Show quoted text

Regards

Pavel

--
Thomas Munro
http://www.enterprisedb.com

Attachments:

xml-xpath-default-ns-6.patchtext/x-patch; charset=US-ASCII; name=xml-xpath-default-ns-6.patchDownload+665-14
#15Michael Paquier
michael@paquier.xyz
In reply to: Pavel Stehule (#14)
Re: [HACKERS] proposal - Default namespaces for XPath expressions (PostgreSQL 11)

On Sat, Nov 25, 2017 at 2:32 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote:

fixed regress test

The last patch still applies, but did not get any reviews.
Horiguchi-san, you are marked as a reviewer of this patch. Could you
look at it? For now, I am moving it to next CF.
--
Michael

#16Kyotaro Horiguchi
horikyota.ntt@gmail.com
In reply to: Michael Paquier (#15)
Re: [HACKERS] proposal - Default namespaces for XPath expressions (PostgreSQL 11)

At Wed, 29 Nov 2017 14:33:08 +0900, Michael Paquier <michael.paquier@gmail.com> wrote in <CAB7nPqROox3HnfjTGhKo4NA97oX8g1DSr0LULWVYsaKHuYqZEw@mail.gmail.com>

On Sat, Nov 25, 2017 at 2:32 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote:

fixed regress test

The last patch still applies, but did not get any reviews.
Horiguchi-san, you are marked as a reviewer of this patch. Could you
look at it? For now, I am moving it to next CF.

Sorry for the absense. It is near to complete. I'll look this soon.

regards,

--
Kyotaro Horiguchi
NTT Open Source Software Center

#17Kyotaro Horiguchi
horikyota.ntt@gmail.com
In reply to: Pavel Stehule (#14)
Re: [HACKERS] proposal - Default namespaces for XPath expressions (PostgreSQL 11)

Hello, I returned to this.

I thouroughly checked the translator's behavior against the XPath
specifications and checkd out the documentation and regression
test. Almost everything is fine for me and this would be the last
comment from me.

At Fri, 24 Nov 2017 18:32:43 +0100, Pavel Stehule <pavel.stehule@gmail.com> wrote in <CAFj8pRB7Fs_2DrtUTGhTmQb+KReXPH6SG62hGWO3KVL_eZYCaA@mail.gmail.com>

2017-11-24 18:13 GMT+01:00 Pavel Stehule <pavel.stehule@gmail.com>:

2017-11-24 17:53 GMT+01:00 Pavel Stehule <pavel.stehule@gmail.com>:

Hi

2017-11-22 22:49 GMT+01:00 Thomas Munro <thomas.munro@enterprisedb.com>:

On Thu, Nov 9, 2017 at 10:11 PM, Pavel Stehule <pavel.stehule@gmail.com>
wrote:

Attached new version.

Hi Pavel,

FYI my patch testing robot says[1]:

xml ... FAILED

regression.diffs says:

+ SELECT x.* FROM t1, xmltable(XMLNAMESPACES(DEFAULT 'http://x.y'),
'/rows/row' PASSING t1.doc COLUMNS data int PATH
'child::a[1][attribute::hoge="haha"]') as x;
+ data
+ ------
+ (0 rows)
+

Maybe you forgot to git-add the expected file?

[1] https://travis-ci.org/postgresql-cfbot/postgresql/builds/305979133

unfortunately xml.out has 3 versions and is possible so one version
should be taken elsewhere than my comp.

please can me send your result xml.out file?

looks like this case is without xml support so I can fix on my comp.

fixed regress test

(I wouldn't have found that..)

I have three comments on the behavior and one on documentation.

1. Lack of syntax handling.

["'" [^'] "'"] is also a string literal, but getXPathToken is
forgetting that and applying default namespace mistakenly to the
astring content.

2. Additional comment might be good.

It might be better having additional description about default
namespace in the comment starts from "Namespace mappings are
passed as text[]" in xpth_internal().

3. Inconsistent behavior from named namespace.

| - function context, aliases are <emphasis>local</emphasis>).
| + function context, aliases are <emphasis>local</emphasis>). Default namespace has
| + empty name (empty string) and should be only one.

This works as the description, on the other hand the same
namespace prefix can be defined twice or more in the array and
the last one is in effect. I don't see a reason for
differenciating the default namespace case.

4. Comments on the documentation part.

# Even though I'm not sutable for commenting on wording...

| + Inside predicate literals <literal>and</literal>, <literal>or</literal>,
| + <literal>div</literal> and <literal>mod</literal> are used as keywords
| + (XPath operators) every time and default namespace are not applied there.

*I*'d like to have a comma between the predicate and literals,
and have a 'a' before prediate. Or 'Literals .. inside a
predicate' might be better?

'are used as keywords' might be better being 'are identifed as
keywords'?

Default namespace is applied to tag names except the listed
keywords even inside a predicate. So 'are not applied there'
might be better being 'are not applied to them'? Or 'are not
applied in the case'?

| + If you would to use these literals like tag names, then the default namespace
| + should not be used, and these literals should be explicitly
| + labeled.
| + </para>

Default namespace is not applied *only to* such keywords inside a
predicate. Even if an Xpath expression contains such a tag name,
default namespace still works for other tags. Does the following
make sense?

+ Use named namespace to qualify such tag names appear in an
+ XPath predicate.

===
After the aboves are addressed (even or rejected), I think I
don't have no additional comment.

- This current patch applies safely (with small shifts) on the
current master.

- The code looks fine for me.

- This patch translates the given XPath expression by prefixing
unprefixed tag names with a special namespace prefix only in
the case where default namespace is defined, so the existing
behavior is not affected.

- The syntax is existing but just not implemented so I don't
think no arguemnts needed here.

- It undocumentedly inhibits the usage of the namespace prefix
"pgdefnamespace.pgsqlxml.internal" but I believe no one can
notice that.

- The default-ns translator (xpath_parser.c) seems working
perfectly with some harmless exceptions.

(xpath specifications is here: https://www.w3.org/TR/1999/REC-xpath-19991116/)

Related unused features (and not documented?):
context variables ($n notations),
user-defined functions (or function names prefixed by a namespace prefix)

Newly documented behavior:
the default namespace isn't applied to and/or/div/mod.

- Dodumentation looks enough.

- Regression test doesn't cover the XPath syntax but it's not
viable. I am fine with the basic test cases added by the
current patch.

regards,

--
Kyotaro Horiguchi
NTT Open Source Software Center

#18Pavel Stehule
pavel.stehule@gmail.com
In reply to: Kyotaro Horiguchi (#17)
Re: [HACKERS] proposal - Default namespaces for XPath expressions (PostgreSQL 11)

Hi

2018-01-23 8:13 GMT+01:00 Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp

:

Hello, I returned to this.

I thouroughly checked the translator's behavior against the XPath
specifications and checkd out the documentation and regression
test. Almost everything is fine for me and this would be the last
comment from me.

At Fri, 24 Nov 2017 18:32:43 +0100, Pavel Stehule <pavel.stehule@gmail.com>
wrote in <CAFj8pRB7Fs_2DrtUTGhTmQb+KReXPH6SG62hGWO3KVL_eZYCaA@
mail.gmail.com>

2017-11-24 18:13 GMT+01:00 Pavel Stehule <pavel.stehule@gmail.com>:

2017-11-24 17:53 GMT+01:00 Pavel Stehule <pavel.stehule@gmail.com>:

Hi

2017-11-22 22:49 GMT+01:00 Thomas Munro <

thomas.munro@enterprisedb.com>:

On Thu, Nov 9, 2017 at 10:11 PM, Pavel Stehule <

pavel.stehule@gmail.com>

wrote:

Attached new version.

Hi Pavel,

FYI my patch testing robot says[1]:

xml ... FAILED

regression.diffs says:

+ SELECT x.* FROM t1, xmltable(XMLNAMESPACES(DEFAULT 'http://x.y'),
'/rows/row' PASSING t1.doc COLUMNS data int PATH
'child::a[1][attribute::hoge="haha"]') as x;
+ data
+ ------
+ (0 rows)
+

Maybe you forgot to git-add the expected file?

[1] https://travis-ci.org/postgresql-cfbot/postgresql/

builds/305979133

unfortunately xml.out has 3 versions and is possible so one version
should be taken elsewhere than my comp.

please can me send your result xml.out file?

looks like this case is without xml support so I can fix on my comp.

fixed regress test

(I wouldn't have found that..)

I have three comments on the behavior and one on documentation.

1. Lack of syntax handling.

["'" [^'] "'"] is also a string literal, but getXPathToken is
forgetting that and applying default namespace mistakenly to the
astring content.

2. Additional comment might be good.

It might be better having additional description about default
namespace in the comment starts from "Namespace mappings are
passed as text[]" in xpth_internal().

3. Inconsistent behavior from named namespace.

| - function context, aliases are <emphasis>local</emphasis>).
| + function context, aliases are <emphasis>local</emphasis>). Default
namespace has
| + empty name (empty string) and should be only one.

This works as the description, on the other hand the same
namespace prefix can be defined twice or more in the array and
the last one is in effect. I don't see a reason for
differenciating the default namespace case.

4. Comments on the documentation part.

# Even though I'm not sutable for commenting on wording...

| + Inside predicate literals <literal>and</literal>,
<literal>or</literal>,
| + <literal>div</literal> and <literal>mod</literal> are used as
keywords
| + (XPath operators) every time and default namespace are not applied
there.

*I*'d like to have a comma between the predicate and literals,
and have a 'a' before prediate. Or 'Literals .. inside a
predicate' might be better?

'are used as keywords' might be better being 'are identifed as
keywords'?

Default namespace is applied to tag names except the listed
keywords even inside a predicate. So 'are not applied there'
might be better being 'are not applied to them'? Or 'are not
applied in the case'?

| + If you would to use these literals like tag names, then the
default namespace
| + should not be used, and these literals should be explicitly
| + labeled.
| + </para>

Default namespace is not applied *only to* such keywords inside a
predicate. Even if an Xpath expression contains such a tag name,
default namespace still works for other tags. Does the following
make sense?

+ Use named namespace to qualify such tag names appear in an
+ XPath predicate.

please, can you append examples of mentioned issues. I'll fix it faster.

Thank you very much

Pavel

Show quoted text

===
After the aboves are addressed (even or rejected), I think I
don't have no additional comment.

- This current patch applies safely (with small shifts) on the
current master.

- The code looks fine for me.

- This patch translates the given XPath expression by prefixing
unprefixed tag names with a special namespace prefix only in
the case where default namespace is defined, so the existing
behavior is not affected.

- The syntax is existing but just not implemented so I don't
think no arguemnts needed here.

- It undocumentedly inhibits the usage of the namespace prefix
"pgdefnamespace.pgsqlxml.internal" but I believe no one can
notice that.

- The default-ns translator (xpath_parser.c) seems working
perfectly with some harmless exceptions.

(xpath specifications is here: https://www.w3.org/TR/1999/
REC-xpath-19991116/)

Related unused features (and not documented?):
context variables ($n notations),
user-defined functions (or function names prefixed by a namespace
prefix)

Newly documented behavior:
the default namespace isn't applied to and/or/div/mod.

- Dodumentation looks enough.

- Regression test doesn't cover the XPath syntax but it's not
viable. I am fine with the basic test cases added by the
current patch.

regards,

--
Kyotaro Horiguchi
NTT Open Source Software Center

#19Pavel Stehule
pavel.stehule@gmail.com
In reply to: Kyotaro Horiguchi (#17)
Re: [HACKERS] proposal - Default namespaces for XPath expressions (PostgreSQL 11)

Hi

2018-01-23 8:13 GMT+01:00 Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp

:

Hello, I returned to this.

I thouroughly checked the translator's behavior against the XPath
specifications and checkd out the documentation and regression
test. Almost everything is fine for me and this would be the last
comment from me.

At Fri, 24 Nov 2017 18:32:43 +0100, Pavel Stehule <pavel.stehule@gmail.com>
wrote in <CAFj8pRB7Fs_2DrtUTGhTmQb+KReXPH6SG62hGWO3KVL_eZYCaA@
mail.gmail.com>

2017-11-24 18:13 GMT+01:00 Pavel Stehule <pavel.stehule@gmail.com>:

2017-11-24 17:53 GMT+01:00 Pavel Stehule <pavel.stehule@gmail.com>:

Hi

2017-11-22 22:49 GMT+01:00 Thomas Munro <

thomas.munro@enterprisedb.com>:

On Thu, Nov 9, 2017 at 10:11 PM, Pavel Stehule <

pavel.stehule@gmail.com>

wrote:

Attached new version.

Hi Pavel,

FYI my patch testing robot says[1]:

xml ... FAILED

regression.diffs says:

+ SELECT x.* FROM t1, xmltable(XMLNAMESPACES(DEFAULT 'http://x.y'),
'/rows/row' PASSING t1.doc COLUMNS data int PATH
'child::a[1][attribute::hoge="haha"]') as x;
+ data
+ ------
+ (0 rows)
+

Maybe you forgot to git-add the expected file?

[1] https://travis-ci.org/postgresql-cfbot/postgresql/

builds/305979133

unfortunately xml.out has 3 versions and is possible so one version
should be taken elsewhere than my comp.

please can me send your result xml.out file?

looks like this case is without xml support so I can fix on my comp.

fixed regress test

(I wouldn't have found that..)

I have three comments on the behavior and one on documentation.

1. Lack of syntax handling.

["'" [^'] "'"] is also a string literal, but getXPathToken is
forgetting that and applying default namespace mistakenly to the
astring content.

In this case, I am not sure if I understand well.

Within expressions, literal strings are delimited by single or double
quotation marks, which are also used to delimit XML attributes. To avoid a
quotation mark in an expression being interpreted by the XML processor as
terminating the attribute value the quotation mark can be entered as a
character reference (&quot; or &apos;). Alternatively, the expression can
use single quotation marks if the XML attribute is delimited with double
quotation marks or vice-versa.

So if I understand well, then XML string can looks like ' some " some ' or
" some ' some ". I fixed it.

2. Additional comment might be good.

It might be better having additional description about default
namespace in the comment starts from "Namespace mappings are
passed as text[]" in xpth_internal().

fixed

3. Inconsistent behavior from named namespace.

| - function context, aliases are <emphasis>local</emphasis>).
| + function context, aliases are <emphasis>local</emphasis>). Default
namespace has
| + empty name (empty string) and should be only one.

This works as the description, on the other hand the same
namespace prefix can be defined twice or more in the array and
the last one is in effect. I don't see a reason for
differenciating the default namespace case.

It looks like libxml2 bug. There is no sense to use more than one default
namespace, and although it is inconsistent with other namespaces, I am
thinking so it is correct. Is better to raise error early. In this case
Postgres expects so libxml2 ensure all namespace checks and it is tolerant.
Default namespace is implemented inside Postgres, and I don't see any
advantage of tolerant behave. More default namespaces is disallowed for
XMLTABLE - so some inconsistency there should be. In this case I prefer
raise error to signalize ambiguous or badly formatted input clearly.

4. Comments on the documentation part.

# Even though I'm not sutable for commenting on wording...

| + Inside predicate literals <literal>and</literal>,
<literal>or</literal>,
| + <literal>div</literal> and <literal>mod</literal> are used as
keywords
| + (XPath operators) every time and default namespace are not applied
there.

*I*'d like to have a comma between the predicate and literals,
and have a 'a' before prediate. Or 'Literals .. inside a
predicate' might be better?

fixed

'are used as keywords' might be better being 'are identifed as
keywords'?

fixed

Default namespace is applied to tag names except the listed
keywords even inside a predicate. So 'are not applied there'
might be better being 'are not applied to them'? Or 'are not
applied in the case'?

| + If you would to use these literals like tag names, then the
default namespace
| + should not be used, and these literals should be explicitly
| + labeled.
| + </para>

Default namespace is not applied *only to* such keywords inside a
predicate. Even if an Xpath expression contains such a tag name,
default namespace still works for other tags. Does the following
make sense?

+ Use named namespace to qualify such tag names appear in an
+ XPath predicate.

fixed

I hope so some native speaker finalize doc. It is out of my knowledges
.

===
After the aboves are addressed (even or rejected), I think I
don't have no additional comment.

- This current patch applies safely (with small shifts) on the
current master.

- The code looks fine for me.

- This patch translates the given XPath expression by prefixing
unprefixed tag names with a special namespace prefix only in
the case where default namespace is defined, so the existing
behavior is not affected.

- The syntax is existing but just not implemented so I don't
think no arguemnts needed here.

- It undocumentedly inhibits the usage of the namespace prefix
"pgdefnamespace.pgsqlxml.internal" but I believe no one can
notice that.

- The default-ns translator (xpath_parser.c) seems working
perfectly with some harmless exceptions.

(xpath specifications is here: https://www.w3.org/TR/1999/
REC-xpath-19991116/)

Related unused features (and not documented?):
context variables ($n notations),
user-defined functions (or function names prefixed by a namespace
prefix)

I did some fast check - and these features are not supported by libxml2 -
so it is question if it should be parsed by out xpath parser. So there are
not possible to check it, test it :(

Newly documented behavior:
the default namespace isn't applied to and/or/div/mod.

- Dodumentation looks enough.

- Regression test doesn't cover the XPath syntax but it's not
viable. I am fine with the basic test cases added by the
current patch.

regards,

I am sending updated version.

Very much thanks for very precious review

Pavel

Show quoted text

--
Kyotaro Horiguchi
NTT Open Source Software Center

Attachments:

xml-xpath-default-ns-7.patchtext/x-patch; charset=US-ASCII; name=xml-xpath-default-ns-7.patchDownload+714-14
#20Kyotaro Horiguchi
horikyota.ntt@gmail.com
In reply to: Pavel Stehule (#19)
Re: [HACKERS] proposal - Default namespaces for XPath expressions (PostgreSQL 11)

Hello.

At Wed, 24 Jan 2018 10:30:39 +0100, Pavel Stehule <pavel.stehule@gmail.com> wrote in <CAFj8pRBVUVvG1CXxgrs0UipTziUX6M788z-=L9gQvwAB4UGLeg@mail.gmail.com>

Hi

2018-01-23 8:13 GMT+01:00 Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp

I have three comments on the behavior and one on documentation.

1. Lack of syntax handling.

["'" [^'] "'"] is also a string literal, but getXPathToken is
forgetting that and applying default namespace mistakenly to the
astring content.

In this case, I am not sure if I understand well.

Within expressions, literal strings are delimited by single or double
quotation marks, which are also used to delimit XML attributes. To avoid a
quotation mark in an expression being interpreted by the XML processor as
terminating the attribute value the quotation mark can be entered as a
character reference (&quot; or &apos;). Alternatively, the expression can
use single quotation marks if the XML attribute is delimited with double
quotation marks or vice-versa.

I think it is correct understanding.

So if I understand well, then XML string can looks like ' some " some ' or
" some ' some ". I fixed it.

Thanks. It looks good.

2. Additional comment might be good.

It might be better having additional description about default
namespace in the comment starts from "Namespace mappings are
passed as text[]" in xpth_internal().

fixed

Thanks.

3. Inconsistent behavior from named namespace.

| - function context, aliases are <emphasis>local</emphasis>).
| + function context, aliases are <emphasis>local</emphasis>). Default
namespace has
| + empty name (empty string) and should be only one.

This works as the description, on the other hand the same
namespace prefix can be defined twice or more in the array and
the last one is in effect. I don't see a reason for
differenciating the default namespace case.

It looks like libxml2 bug. There is no sense to use more than one default
namespace, and although it is inconsistent with other namespaces, I am
thinking so it is correct. Is better to raise error early. In this case
Postgres expects so libxml2 ensure all namespace checks and it is tolerant.
Default namespace is implemented inside Postgres, and I don't see any
advantage of tolerant behave. More default namespaces is disallowed for
XMLTABLE - so some inconsistency there should be. In this case I prefer
raise error to signalize ambiguous or badly formatted input clearly.

Ok. I'm fine with that.

4. Comments on the documentation part.

# Even though I'm not sutable for commenting on wording...

| + Inside predicate literals <literal>and</literal>,
<literal>or</literal>,
| + <literal>div</literal> and <literal>mod</literal> are used as
keywords
| + (XPath operators) every time and default namespace are not applied
there.

*I*'d like to have a comma between the predicate and literals,
and have a 'a' before prediate. Or 'Literals .. inside a
predicate' might be better?

fixed

'are used as keywords' might be better being 'are identifed as
keywords'?

fixed

Default namespace is applied to tag names except the listed
keywords even inside a predicate. So 'are not applied there'
might be better being 'are not applied to them'? Or 'are not
applied in the case'?

| + If you would to use these literals like tag names, then the
default namespace
| + should not be used, and these literals should be explicitly
| + labeled.
| + </para>

Default namespace is not applied *only to* such keywords inside a
predicate. Even if an Xpath expression contains such a tag name,
default namespace still works for other tags. Does the following
make sense?

+ Use named namespace to qualify such tag names appear in an
+ XPath predicate.

fixed

I hope so some native speaker finalize doc. It is out of my knowledges
.

I am also anxious for that.

===
After the aboves are addressed (even or rejected), I think I
don't have no additional comment.

- This current patch applies safely (with small shifts) on the
current master.

- The code looks fine for me.

- This patch translates the given XPath expression by prefixing
unprefixed tag names with a special namespace prefix only in
the case where default namespace is defined, so the existing
behavior is not affected.

- The syntax is existing but just not implemented so I don't
think no arguemnts needed here.

- It undocumentedly inhibits the usage of the namespace prefix
"pgdefnamespace.pgsqlxml.internal" but I believe no one can
notice that.

- The default-ns translator (xpath_parser.c) seems working
perfectly with some harmless exceptions.

(xpath specifications is here: https://www.w3.org/TR/1999/
REC-xpath-19991116/)

Related unused features (and not documented?):
context variables ($n notations),
user-defined functions (or function names prefixed by a namespace
prefix)

I did some fast check - and these features are not supported by libxml2 -
so it is question if it should be parsed by out xpath parser. So there are
not possible to check it, test it :(

I'm fine with that. I don't think that test for them is needed
since PostgreSQL doesn't support them anyway. Sorry for the
confusing comment. (libxml2 complains about that in the following
way.)

| =# select xpath('/a/text()=$', '<a>test</a>');
| ERROR: invalid XPath expression
!| DETAIL: Expected $ for variable reference
| CONTEXT: SQL function "xpath" statement 1

| =# select xpath('func(/a/text())', '<a>test</a>');
| ERROR: could not create XPath object
!| DETAIL: Unregistered function
| CONTEXT: SQL function "xpath" statement 1

Newly documented behavior:
the default namespace isn't applied to and/or/div/mod.

- Dodumentation looks enough.

- Regression test doesn't cover the XPath syntax but it's not
viable. I am fine with the basic test cases added by the
current patch.

regards,

I am sending updated version.

Very much thanks for very precious review

It's my pleasure. Sorry for my slow responses.

--
Kyotaro Horiguchi
NTT Open Source Software Center

#21Kyotaro Horiguchi
horikyota.ntt@gmail.com
In reply to: Kyotaro Horiguchi (#20)
#22Andrew Dunstan
andrew@dunslane.net
In reply to: Pavel Stehule (#19)
#23Thomas Munro
thomas.munro@gmail.com
In reply to: Andrew Dunstan (#22)
#24Pavel Stehule
pavel.stehule@gmail.com
In reply to: Thomas Munro (#23)
#25Thomas Munro
thomas.munro@gmail.com
In reply to: Pavel Stehule (#24)
#26Pavel Stehule
pavel.stehule@gmail.com
In reply to: Thomas Munro (#25)
#27Tom Lane
tgl@sss.pgh.pa.us
In reply to: Pavel Stehule (#19)
#28Pavel Stehule
pavel.stehule@gmail.com
In reply to: Tom Lane (#27)
#29Dmitry Dolgov
9erthalion6@gmail.com
In reply to: Pavel Stehule (#28)
#30Pavel Stehule
pavel.stehule@gmail.com
In reply to: Dmitry Dolgov (#29)
#31Kyotaro Horiguchi
horikyota.ntt@gmail.com
In reply to: Pavel Stehule (#30)
#32Pavel Stehule
pavel.stehule@gmail.com
In reply to: Kyotaro Horiguchi (#31)
#33Andres Freund
andres@anarazel.de
In reply to: Tom Lane (#27)
#34Pavel Stehule
pavel.stehule@gmail.com
In reply to: Andres Freund (#33)
#35Michael Paquier
michael@paquier.xyz
In reply to: Pavel Stehule (#34)