Horton

Re: Fix search_path for all maintenance commands

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Isaac Morland <isaac.morland@gmail.com>
Cc: Jeff Davis <pgsql@j-davis.com>, Nathan Bossart <nathandbossart@gmail.com>, Noah Misch <noah@leadboat.com>, "David G. Johnston" <david.g.johnston@gmail.com>, Gurjeet Singh <gurjeet@singh.im>, pgsql-hackers@postgresql.org, Robert Haas <robertmhaas@gmail.com>, Greg Stark <stark@mit.edu>
Date: 2023-11-06T20:53:59Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Fix search_path to a safe value during maintenance operations.

  2. Make relation-enumerating operations be security-restricted operations.

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