On Mon, Aug 21, 2023 at 5:32 PM Jeff Davis <pg...@j-davis.com> wrote: > But I don't look at the search_path as "just another GUC" when it comes > to executing a function. The source of the initial value of search_path > is more like the IMMUTABLE marker.
I mean I agree and I disagree. Philosophically, I agree. Most functions are written with some particular search_path in mind; the author imagines that the function will be executed with, well, probably whatever search path the author typically uses themselves. Now and then, someone may write a function that's intended to run with various different search paths, e.g. anything of the form customer_XXXX, pg_catalog, pg_temp. I think that is a real thing that people actually do, intentionally varying the search_path with the idea of rebinding some references. However, cases where somebody sincerely intends for the caller to be able to make + or || mean something different from normal probably do not exist in practice. So, if we were designing a system from scratch, then I would recommend against making search_path a GUC, because it's clearly shouldn't behave in the same way as a session property like debug_print_plan or enable_seqscan, where you could want to run the same code with various values. But practically, I disagree. As things stand today, search_path *is* a GUC that dynamically changes the run-time properties of a session, and your proposed patch wouldn't change that. What it would do is layer another mechanism on top of that which, IMHO, makes something that is already complicated and error-prone even more complicated. If we wanted to really make seach_path behave like a property of the code rather than the session, I think we'd need to change quite a bit more stuff, and the price of that in terms of backward-compatibility might be higher than we'd be willing to pay, but if, hypothetically, we decided to pay that price, then at the end of it search_path as a GUC would be gone, and we'd have one way of managing sarch_path that is different from the one we have now. But with the patch as you have proposed it that's not what happens. We just end up with two interconnected mechanisms for managing what, right now, is managed by a single mechanism. That mechanism is (and I think we probably mostly all agree on this) bad. Like really really bad. But having more than one mechanism, to me, still seems worse. -- Robert Haas EDB: http://www.enterprisedb.com
