2012/8/7 Peter Geoghegan <pe...@2ndquadrant.com>: > On 7 August 2012 20:01, Andrew Dunstan <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers