Re: Deparsing rewritten query

Le 27/06/2021 à 17:14, Tom Lane a écrit :
> Julien Rouhaud <rjuju123(at)gmail(dot)com> writes:
>> On Sun, Jun 27, 2021 at 10:34:52AM -0400, Tom Lane wrote:
>>> It's not very hard to imagine someday moving view
>>> expansion into the planner on efficiency grounds, leaving the rewriter
>>> handling only the rare uses of INSERT/UPDATE/DELETE rules.
>> Agreed. One the other hand having such a function in core may ensure that any
>> significant change in those area will keep an API to retrieve the final query
>> representation.
> My point is precisely that I'm unwilling to make such a promise.
>
> I do not buy that this capability is worth very much, given that
> we've gotten along fine without it for twenty-plus years. If you
> want to have it as an internal, might-change-at-any-time API,
> that seems all right. If you're trying to lock it down as something
> that will be there forevermore, you're likely to end up with nothing.
>
> regards, tom lane

I have to say that such feature would be very helpful for some DBA and
especially migration work. The problem is when you have tons of views
that call other views in the from or join clauses. These views also call
other views, etc. I have had instances where there were up to 25 nested
views calls. When you want to clean up this kind of code, using
get_query_def () will help save a lot of manual rewrite time and
headache to get the final code executed.

If we could at least call get_query_def()through an extension if we
didn't have a functionit would be ideal for DBAs.I agree this is unusual
but when it does happen to you being able to call get_query_def () helps
a lot.

--
Gilles Darold
http://www.darold.net/