Re: WIP: pg_pretty_query - Mailing list pgsql-hackers

From Tom Lane
Subject Re: WIP: pg_pretty_query
Date
Msg-id 3361.1344369483@sss.pgh.pa.us
Whole thread Raw
In response to Re: WIP: pg_pretty_query  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: WIP: pg_pretty_query
List pgsql-hackers
Andrew Dunstan <andrew@dunslane.net> writes:
> On 08/07/2012 02:14 PM, Tom Lane wrote:
>> In short, the only redeeming value of this patch is that it's short.

> 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.

Sure.  I think if we wanted an actually engineered solution, rather than
a half-baked one, ecpg provides a good source of inspiration.  One could
imagine a standalone program that reads a query on stdin and emits a
pretty-printed version to stdout, using a parser that is automatically
generated from the backend's grammar with much the same technology used
in recent ecpg releases.  I think that would address most of the
complaints I raised: it would be relatively painless to make use of from
contexts that don't have a live database connection, it wouldn't impose
any constraints related to having suitable database content available,
it wouldn't apply any of the multitude of implementation-dependent
transformations that the backend's parser does, and it could be built
(I think) to do something more with comments than just throw them away.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: WIP: pg_pretty_query
Next
From: Jeff Janes
Date:
Subject: Re: Inserting heap tuples in bulk in COPY