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.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 > -- Regards, Ashoke
