Re: Deparsing rewritten query - Mailing list pgsql-hackers

From Ranier Vilela
Subject Re: Deparsing rewritten query
Date
Msg-id CAEudQAp1kX+G_uG3ZfyCDsdff4ue-vmwbWQzRwWb4oPYOFpunA@mail.gmail.com
Whole thread Raw
In response to Deparsing rewritten query  (Julien Rouhaud <rjuju123@gmail.com>)
Responses Re: Deparsing rewritten query
List pgsql-hackers
> Hi,
>
> I sometimes have to deal with queries referencing multiple and/or complex
> views. In such cases, it's quite troublesome to figure out what is the
> query
> really executed. Debug_print_rewritten isn't really useful for non trivial
> queries, and manually doing the view expansion isn't great either.
>
> While not being ideal, I wouldn't mind using a custom extension for that
> but
> this isn't an option as get_query_def() is private and isn't likely to
> change.
>
> As an alternative, maybe we could expose a simple SRF that would take care
> of
> rewriting the query and deparsing the resulting query tree(s)?
>
> I'm attaching a POC patch for that, adding a new pg_get_query_def(text)
> SRF.
+1

If you don't mind, I made small corrections to your patch.
1. strcmp(sql, "") could not be replaced by sql[0] == '\0'?
2. the error message would not be: "empty statement not allowed"?
3. initStringInfo(&buf) inside a loop, wouldn't it be exaggerated? each time call palloc0.

regards,
Ranier Vilela

Attachment

pgsql-hackers by date:

Previous
From: Andrey Borodin
Date:
Subject: Re: pglz compression performance, take two
Next
From: Julien Rouhaud
Date:
Subject: Re: Deparsing rewritten query