Обсуждение: 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

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

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