| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Julien Rouhaud <rjuju123(at)gmail(dot)com> |
| Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Deparsing rewritten query |
| Date: | 2021-06-27 15:14:05 |
| Message-ID: | 8085.1624806845@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Julien Rouhaud | 2021-06-27 15:21:37 | Re: Deparsing rewritten query |
| Previous Message | Julien Rouhaud | 2021-06-27 15:03:43 | Re: Deparsing rewritten query |