Re: WIP: pg_pretty_query
| От | Tom Lane |
|---|---|
| Тема | Re: WIP: pg_pretty_query |
| Дата | |
| Msg-id | 3361.1344369483@sss.pgh.pa.us обсуждение |
| Ответ на | Re: WIP: pg_pretty_query (Andrew Dunstan <andrew@dunslane.net>) |
| Ответы |
Re: WIP: pg_pretty_query
|
| Список | 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 по дате отправления: