Re: Fix search_path for all maintenance commands - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Fix search_path for all maintenance commands
Date
Msg-id 4108706.1699304039@sss.pgh.pa.us
Whole thread Raw
In response to Re: Fix search_path for all maintenance commands  (Isaac Morland <isaac.morland@gmail.com>)
Responses Re: Fix search_path for all maintenance commands
List pgsql-hackers
Isaac Morland <isaac.morland@gmail.com> writes:
> I still think the right default is that CREATE FUNCTION stores the
> search_path in effect when it runs with the function, and that is the
> search_path used to run the function (and don't "BEGIN ATOMIC" functions
> partially work this way already?).

I don't see how that would possibly fly.  Yeah, that behavior is
often what you want, but not always; we would break some peoples'
applications with that rule.

Also, one place where it's clearly NOT what you want is while
restoring a pg_dump script.  And we don't have any way that we could
bootstrap ourselves out of breaking everything for everybody during
their next upgrade --- even if you insist that people use a newer
pg_dump, where is it going to find the info in an existing database?

            regards, tom lane



pgsql-hackers by date:

Previous
From: Laurenz Albe
Date:
Subject: Re: Version 14/15 documentation Section "Alter Default Privileges"
Next
From: Alexander Korotkov
Date:
Subject: Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15)