| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Andres Freund <andres(at)anarazel(dot)de>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Add more sanity checks around callers of changeDependencyFor() |
| Date: | 2023-07-11 01:40:37 |
| Message-ID: | ZKyzFVXVW9L6AOFY@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Jul 10, 2023 at 11:04:48AM -0400, Tom Lane wrote:
> ISTR that we discussed forbidding such changes way back when the
> extension mechanism was invented, and decided against it on the
> grounds that (a) it'd be nanny-ism, (b) we'd have to add checks in an
> awful lot of places and it'd be easy to miss some,
The namepace modifications depending on the object types are quite
centralized lately, FWIW. And that was the case in 9.3 as well since
we have ExecAlterObjectSchemaStmt(). It would be easy to miss a new
code path if somebody introduces a new object type that needs its own
update path, but based on the last 15 years of experience on the
matter, that would be unlikely? Adding a note at the top of
ExecAlterObjectSchemaStmt() would make that even harder to miss.
> and (c) forbidding
> superusers from doing anything they want is generally not our style.
Yeah.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Justin Pryzby | 2023-07-11 02:01:37 | pg16b2: REINDEX segv on null pointer in RemoveFromWaitQueue |
| Previous Message | Japin Li | 2023-07-11 01:24:35 | Re: Add hint message for check_log_destination() |