| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Bruce Momjian <bruce(at)momjian(dot)us> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Magnus Hagander <magnus(at)hagander(dot)net>, Noah Misch <noah(at)leadboat(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Which SET TYPE don't actually require a rewrite |
| Date: | 2020-07-22 00:31:12 |
| Message-ID: | 20200722003112.GB9642@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Jul 21, 2020 at 04:55:37PM -0400, Bruce Momjian wrote:
> I know Tom put a wink on that, but I actually do feel that the only
> clean way to do this is to give users a way to issue the query in a
> non-executing way that will report if a rewrite is going to happen.
Yeah, when doing a schema upgrade for an application, that's the usual
performance pin-point and people used to other things than Postgres
write their queries without being aware of that. We have something
able to track that with the event trigger table_rewrite, but there is
no easy option to store the event and bypass its execution. I think
that using a plpgsql function wrapping an ALTER TABLE query with an
exception block for an error generated by an event trigger if seeing
table_rewrite allows to do that, though.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2020-07-22 00:36:12 | Re: v13 planner ERROR: could not determine which collation to use for string comparison |
| Previous Message | David Rowley | 2020-07-21 23:55:17 | Re: Parallel Seq Scan vs kernel read ahead |