Re: WIP: pg_pretty_query
От | Pavel Stehule |
---|---|
Тема | Re: WIP: pg_pretty_query |
Дата | |
Msg-id | CAFj8pRBE59sSywhN+dUWVy6YOMP4jgMz5267nV2Yxtn9ohvzJg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: WIP: pg_pretty_query (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
2012/8/7 Tom Lane <tgl@sss.pgh.pa.us>: > 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. +1 it is better, and it is allow more space for possible styling Pavel > > regards, tom lane
В списке pgsql-hackers по дате отправления: