> What MarkGUCPrefixReserved is really about is detecting > misspelled hand-made config-file entries and SET commands as best we > can.
That's not strictly true, MarkGUCPrefixReserved already implements part of this: 1. If extension A reserves prefix "ext_a" 2. And then extension B tries to register a GUC named "ext_a.something" We get an error. But if these extensions are loaded in the opposite order, everything works fine, extension B can use a variable in a prefix reserved by another extension. If I remove the part about requiring MarkGUCPrefixReserved prefix / printing a warning if it's not called, all this patch does is makes the behavior of MarkGUCPrefixReserved more consistent. My initial goal was simply that (to print out an error even if things happen in a different order), but then I thought maybe also nudging extensions towards reserving prefixes with MarkGUCPrefixReserved would be useful. > I'm also skeptical that there's any > real-world problem that needs solving here This came up based on a discussion on how MarkGUCPrefixReserved works, and what exactly does it prevent, because it's not really consistent/intuitive currently. I personally thought that it already enforces that only that extension can use the prefix, and I was surprised when I discovered that it is only half true. What do you think about a simplified version, which only solves the original problem - properly reporting errors regardless of the order of library loading, if MarkGUCPrefixReserved is used?
