From: Tom Lane <tgl@sss.pgh.pa.us>
To: Julien Rouhaud <rjuju123@gmail.com>
cc: pgsql-hackers@lists.postgresql.org
Subject: Re: Deparsing rewritten query
In-reply-to: <20210627150343.zslwnw7g564f2zz4@nol>
References: <20210627041138.zklczwmu3ms4ufnk@nol>
 <3176554.1624804492@sss.pgh.pa.us> <20210627150343.zslwnw7g564f2zz4@nol>
Comments: In-reply-to Julien Rouhaud <rjuju123@gmail.com>
	message dated "Sun, 27 Jun 2021 23:03:43 +0800"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <8084.1624806845.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Sun, 27 Jun 2021 11:14:05 -0400
Message-ID: <8085.1624806845@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/8085.1624806845%40sss.pgh.pa.us>
Precedence: bulk

Julien Rouhaud <rjuju123@gmail.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 th=
at 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