From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: WIP: pg_pretty_query |
Date: | 2012-08-07 19:58:03 |
Message-ID: | 3361.1344369483@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andrew Dunstan <andrew(at)dunslane(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2012-08-07 20:10:11 | Re: WIP: pg_pretty_query |
Previous Message | Andrew Dunstan | 2012-08-07 19:01:12 | Re: WIP: pg_pretty_query |