Re: reparsing query

From: Lukas Fittl <lukas(at)fittl(dot)com>
To: Qingqing Zhou <zhouqq(dot)postgres(at)gmail(dot)com>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Andrzej Barszcz <abusinf(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: reparsing query
Date: 2015-04-16 04:36:32
Message-ID: CAP53Pky1-K5y1EZypmdhPvzH3UoUd3SLdrokte4-fktydDeStw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Apr 15, 2015 at 8:39 PM, Qingqing Zhou <zhouqq(dot)postgres(at)gmail(dot)com>
wrote:
>
> It is not difficult to output parsed query in some tool readable
> format but it comes with a maintain overhead: once tools rely on it,
> we have to conform to some schema continuously, like the xml/xmlns. Do
> we want to take this? Depends on how far the tools can go with this
> exposed information.
>
> We actually already have explain command in json format and tools
> drawing/analyzing query plan rely on it. Will that work for your
> scenario?
>

Sure, that would work - but as I understand adding an explicit SQL command
(or function) is not something that would ever be merged into Postgres
core. Especially since that command's output could easily change across
versions.

My thought was more along the lines of making something like raw_parser +
nodeToString available through an extension, but with a JSON output format.

Note that an important detail in the monitoring case is that you don't
necessarily have the statement's underlying relations available (since you
might work with statistics data on a different machine).

Best,
Lukas

--
Lukas Fittl

Skype: lfittl
Phone: +1 415 321 0630

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro HORIGUCHI 2015-04-16 06:18:08 Re: inherit support for foreign tables
Previous Message Michael Paquier 2015-04-16 04:00:28 Re: Improve sleep processing of pg_rewind TAP tests