Postgresql XML parsing

On 03/12/2014 09:36 AM, Ashoke wrote:

Hi,

I am working on adding a functionality to PostgreSQL. I need to
parse the XML format query plan (produced by PostgreSQL v9.3) and save
it in a simple data structure (say C structure). I was wondering if
PostgreSQL already had any parsing functions implemented that I can
use to do the XML parsing. This is getting difficult as I was not able
to get any DTD or XML Schema for the XML files generated by PostgreSQL.

I found the files xpath.c/xslt_proc.c files that contain parsing
related code, but none of the functions are being called for any xml
related query I issue to the database and some of the functions in
those files mention as deprecated.

It would be greatly helpful if someone could guide me on this.

The only XML parsing we have is where Postgres is built with libxml, in
which case we use its parser. But query plan XML is delivered to a
client (or a log file, which means more or less the same thing here). If
you want to parse it then it should be parsed in the client - that's why
we provide it. Inside postgres I don't see a point in parsing the XML
rather than handling the query plan directly.

The worst possible option would be to make a hand-cut XML parser, either
in the client or the server - XML parsing has all sorts of wrinkles that
can bite you badly.

cheers

andrew

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

Hello,

On 03/12/2014 09:36 AM, Ashoke wrote:

Hi,

I am working on adding a functionality to PostgreSQL. I need to parse
the XML format query plan (produced by PostgreSQL v9.3) and save it in
a simple data structure (say C structure). I was wondering if

...

The only XML parsing we have is where Postgres is built with libxml,
in which case we use its parser. But query plan XML is delivered to a
client (or a log file, which means more or less the same thing
here).

As a HACKERS' matter, explain output can be obtained from
ExplainPrintPlan() in any format in backend. I don't know if it
is the case though.

If you want to parse it then it should be parsed in the client
- that's why we provide it. Inside postgres I don't see a point in
parsing the XML rather than handling the query plan directly.

The worst possible option would be to make a hand-cut XML parser,
either in the client or the server - XML parsing has all sorts of
wrinkles that can bite you badly.

I agree with it. If XML input is not essential, JSON format would
be parsed more easily than xml. 9.3 already intrinsically has a
JSON parser infrastructure available for the purpose.

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

Hi,

Thanks for the input. I would look into JSON parsing as well, but the
requirement is XML parsing.

There is no DTD/Schema for the XML. Is there any way I could know what
are the possible tags and their values? I am building my parser based on
the output PostgreSQL produces (hard coding the tags) and I am afraid I
would miss out on tags.

Thank you.

On Thu, Mar 13, 2014 at 5:47 AM, Kyotaro HORIGUCHI <
horiguchi.kyotaro@lab.ntt.co.jp> wrote:

Hello,

On 03/12/2014 09:36 AM, Ashoke wrote:

Hi,

I am working on adding a functionality to PostgreSQL. I need to

parse

the XML format query plan (produced by PostgreSQL v9.3) and save it

in

a simple data structure (say C structure). I was wondering if

...

The only XML parsing we have is where Postgres is built with libxml,
in which case we use its parser. But query plan XML is delivered to a
client (or a log file, which means more or less the same thing
here).

As a HACKERS' matter, explain output can be obtained from
ExplainPrintPlan() in any format in backend. I don't know if it
is the case though.

If you want to parse it then it should be parsed in the client
- that's why we provide it. Inside postgres I don't see a point in
parsing the XML rather than handling the query plan directly.

The worst possible option would be to make a hand-cut XML parser,
either in the client or the server - XML parsing has all sorts of
wrinkles that can bite you badly.

I agree with it. If XML input is not essential, JSON format would
be parsed more easily than xml. 9.3 already intrinsically has a
JSON parser infrastructure available for the purpose.

regards,

--
Kyotaro Horiguchi
NTT Open Source Software Center

--
Regards,
Ashoke

On 03/13/2014 11:27 AM, Ashoke wrote:

Hi,

Thanks for the input. I would look into JSON parsing as well, but
the requirement is XML parsing.

There is no DTD/Schema for the XML. Is there any way I could know
what are the possible tags and their values? I am building my parser
based on the output PostgreSQL produces (hard coding the tags) and I
am afraid I would miss out on tags.

No, it's not possible, since modules can hook in and add their own nodes
with arbitrary names (see for example the Postgres FDW which does this).
You need to be able to handle arbitrary tags, even if it's by ignoring them.

cheers

andrew

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