Robert Haas <robertmh...@gmail.com> writes: > There are some things that are pretty hard to change once we've > released them. For example, if we had a function or operator and > somebody embeds it in a view definition, removing or renaming it > prevents people from upgrading. But GUCs are not as bad.
Really? Are we certain that nobody will put SETs of this GUC into their applications, or even just activate it via ALTER DATABASE SET? If they've done that, then a GUC change means dump/reload/upgrade failure. I've not been following this thread, so I don't have an opinion about what the design ought to be. But if we still aren't settled on it by now, I think the prudent thing is to revert the feature out of v17 altogether, and try again in v18. When we're still designing something after feature freeze, that is a good indication that we are trying to ship something that's not ready for prime time. regards, tom lane