From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
Cc: | Vaibhav Dalvi <vaibhav(dot)dalvi(at)enterprisedb(dot)com>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: pg_upgrade fails with an error "object doesn't exist" |
Date: | 2025-06-16 13:41:07 |
Message-ID: | 516031.1750081267@sss.pgh.pa.us |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Daniel Gustafsson <daniel(at)yesql(dot)se> writes:
> On 16 Jun 2025, at 09:29, Vaibhav Dalvi <vaibhav(dot)dalvi(at)enterprisedb(dot)com> wrote:
>> Why can't we strictly restrict object creation in pg_catalog?
> Do you have allow_system_table_mods set to ON by any chance? As Laurenz said,
> such creation is already restricted, but it can be circumvented by using said
> GUC (which is *not* intended for production usage).
I think that setting only applies to creating or modifying *tables*,
not functions. The point of it is to keep you from breaking the C
code's assumptions about the layout of system catalogs.
Having said that, I don't see a problem here. You're not going
to be able to create/modify functions in pg_catalog unless you
are superuser (or a superuser gave you permissions you shouldn't
have). There are already a near-infinite number of ways
for a superuser to break the system, so this one isn't making it
detectably worse. Furthermore, there are legitimate use-cases
for adding/changing functions there. (I recall that the old
"adminpack" extension used to do so, for example, and there are
probably others that still do.)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2025-06-16 13:56:06 | Re: No error checking when reading from file using zstd in pg_dump |
Previous Message | Yugo Nagata | 2025-06-16 13:37:43 | Re: relrewrite not documented at the top of heap_create_with_catalog() |