On 2022-Mar-07, Greg Stark wrote: > I don't think this is worth spending time adding tests for. I get what > you're saying that this is at least semi-intentional behaviour and > desirable behaviour so it should have tests ensuring that it continues > to work. But it's not documented behaviour and the test is basically > testing that the implementation is this specific implementation. > > I don't think the test is really a bad idea but neither is it really > very useful and I think it's not worth having people spend time > reviewing and discussing. I'm leaning to saying this patch is > rejected.
I've pushed this patch; I agree with Greg that this is semi-intentional and desirable, even if not documented. (I doubt we would document it anyway, as having previously SET an invalid option is not something that happens commonly; what reason would we have for documenting that it works to RESET such an option?) As for the implementation being this specific one, that's something already embedded in all of reloptions.sql, so I don't really mind that, if we do change it, we'll have to rewrite pretty much the whole file and not "the whole file except these three lines". Lastly, there is a long-running patch proposal to refactor reloptions quite significantly, so it'll be good to ensure that the new implementation doesn't break the features we already have; and this one corner is one thing Nikolay already said his patch had broken and failed to notice right away. -- Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/ "La verdad no siempre es bonita, pero el hambre de ella sí"