Re: WIP: pg_pretty_query - Mailing list pgsql-hackers

2012/8/7 Peter Geoghegan <peter@2ndquadrant.com>:
> On 7 August 2012 20:01, Andrew Dunstan <andrew@dunslane.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).

I disagree - simply pretty printer based on technique that we know
from ecpg can be very cheep and it cannot be "fuzzy" because it
integrate PostgreSQL parser.

Pavel

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