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.kyot...@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


Reply via email to