Re: WIP: pg_pretty_query

On 7 August 2012 20:01, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
> On 08/07/2012 02:14 PM, Tom Lane wrote:
>> * As per some of the complaints already registered in this thread,
>> ruleutils.c is not designed with the goal of being a pretty-printer.
>> Its primary charter is to support pg_dump by regurgitating rules/views
>> in an unambiguous form, which does not necessarily look very similar to
>> what was entered. An example of a transformation that probably nobody
>> would want in a typical pretty-printing context is expansion of
>> "SELECT *" lists. But again, there is really no way to turn that off.
>> Another aspect that seems pretty undesirable for pretty-printing is
>> loss of any comments embedded in the query text.
>>
>> I'm very much not in favor of trying to make ruleutils serve two
>> masters, but that's the game we will be playing if we accept this patch.

+1. A pretty-printer that makes the query to be cleaned-up actually
undergo parse-analysis seems misconceived to me. This is a tool that
begs to be written in something like Python, as a satellite project,
with much greater flexibility in the format of the SQL that it
outputs.

> One of the challenges is to have a pretty printer that is kept in sync with
> the dialect that's supported. Anything that doesn't use the backend's parser
> seems to me to be guaranteed to get out of sync very quickly.

I'm not convinced of that. Consider the example of cscope, a popular
tool for browsing C code. Its parser was written to be "fuzzy", so
it's actually perfectly usable for C++ and Java, even though that
isn't actually supported, IIRC. Now, I'll grant you that that isn't a
perfectly analogous situation, but it is similar in some ways. If we
add a new clause to select and that bit is generically pretty-printed,
is that really so bad? I have a hard time believing that a well
written fuzzy pretty-printer for Postgres wouldn't deliver the vast
majority of the benefits of an in-core approach, at a small fraction
of the effort. You'd also be able to pretty-print plpgsql function
definitions (a particularly compelling case for this kind of tool),
which any approach based on the backends grammar will never be able to
do (except, perhaps, if you were to do something even more
complicated).

--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services