Hi Tom,
Should we at least restrict dumping privileges for user objects inside
pg_catalog to avoid pg_upgrade failure?
Regards,
Vaibhav
On Mon, Jun 16, 2025 at 7:11 PM Tom Lane wrote:
> Daniel Gustafsson writes:
> > On 16 Jun 2025, at 09:29, Vaibhav Dalvi
> wrote:
>
Hi Daniel,
Thanks for your response.
On Mon, Jun 16, 2025 at 1:27 PM Daniel Gustafsson wrote:
> > On 16 Jun 2025, at 09:29, Vaibhav Dalvi
> wrote:
>
> > I'm able to create the object as shown in the below:
> >
> > postgres=# CREATE OR REPLACE FUNCTION pg_cat
Hi Laurenz,
Thanks for the response.
>
>
> > I believe one of the following approaches should be considered to prevent
> > such failures:
> >
> > 1. Restrict the creation of user objects within the `pg_catalog` schema.
>
> That's already the case:
>
> test=# CREATE TABLE pg_catalog.new ();
> ERR
Hi,
I'm writing to share an observation regarding `pg_catalog` system objects
and their privileges during `pg_upgrade`. It's known that `pg_catalog`
system objects are not dumped, but their privileges are. However, if
user-created objects are placed within `pg_catalog` and their privileges
are alt
r *colName, Node *newDefault,
> bool missing_ok, LOCKMODE lockmode);
>
4. Exceeded 80 char limit:
> /*
> * Mark the column as no longer generated. (The atthasdef flag needs to
>
5. Update the comment. Use 'set' along with 'drop':
> AT_ColumnExpression, /* alter column drop expression */
Thanks,
Vaibhav Dalvi
r address but returns the original un-incremented pointer address,
which is then dereferenced. Correct me if I am wrong here.
If my understanding is correct then '++' is not needed in the
above highlighted statement which is leading to overhead.
Find an attached patch which does the same
