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 по дате отправления:

Предыдущее
От: Jeff Janes
Дата:
Сообщение: Re: Inserting heap tuples in bulk in COPY
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: WIP: pg_pretty_query