Bruce Momjian <br...@momjian.us> writes:
> On Tue, Aug 7, 2012 at 04:14:34PM +0200, Pavel Stehule wrote:
>> last year we are spoke about reusing pretty print view code for some queries.
>>
>> Here is patch:
> I can see this as very useful for people reporting badly-formatted
> queries to our email lists. Great!
Allow me to express a contrary opinion: I think this is a bad idea.
* First off, packaging it as a SQL function that takes and returns text
seems rather awkward to use. A lot of places where you might wish for
a SQL pretty-printer aren't going to have a database connection handy
(think "emacs SQL mode").
* The functionality provided is not merely a pretty-printer but sort
of a query validator as well: the function will fail if the query refers
to any tables, columns, functions, etc you don't have in your database.
For some applications that's fine, but others not so much --- in
particular I suspect it's nigh useless for the use-case you mention of
quickly turning an emailed query into something legible. And there's
no way to separate out the reformatting functionality from that.
* As per some of the complaints already registered in this thread,
ruleutils.c is not designed with the goal of being a pretty-printer.
Its primary charter is to support pg_dump by regurgitating rules/views
in an unambiguous form, which does not necessarily look very similar to
what was entered. An example of a transformation that probably nobody
would want in a typical pretty-printing context is expansion of
"SELECT *" lists. But again, there is really no way to turn that off.
Another aspect that seems pretty undesirable for pretty-printing is
loss of any comments embedded in the query text.
I'm very much not in favor of trying to make ruleutils serve two
masters, but that's the game we will be playing if we accept this patch.
In short, the only redeeming value of this patch is that it's short.
The functionality it provides is not something that anyone would come
up with in a green-field design for a pretty-printer, and if we take
it we are going to be faced with a whole lot of redesign requests that
will be painful to implement and will carry heavy risks of breaking
pg_dump and/or EXPLAIN.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
