Noah Misch <noah@leadboat.com> writes:
> On Tue, Feb 26, 2019 at 10:46:29AM -0500, Tom Lane wrote:
>> It'd be nice to get the SupportRequestSimplify API correct from the first
>> release, so if there's even a slightly plausible reason for it to support
>> this, I'd be inclined to err in the direction of doing so.
> Is it problematic to add a volatility field later?
Not hugely so, no. I'm thinking more in terms of support functions
having to pay attention to which version they're being compiled for
to know what they can do. But I suppose that's little worse than
any other feature addition we make at the C API level.
>> ... is it really impossible for the timezone GUC to change during
>> the execution of the ALTER TABLE command? You could probably break that
>> if you tried hard enough, though it seems unlikely that anyone would do so
>> accidentally.
> No, one certainly can change a GUC during ALTER TABLE execution. The STABLE
> marking on current_setting is a fiction. I interpret that fiction as a signal
> that a query has undefined behavior if you change GUCs mid-query, which seems
> like a prudent level of effort toward such queries. Adding a volatility field
> to SupportRequestSimplify does invite C-language extension code to participate
> in deciding this undefined behavior, which would make it harder to verify that
> we like the undefined behavior of the moment (e.g. doesn't crash). Perhaps
> best not to overturn that rock?
Probably not, unless we can come up with more convincing use-cases for
it.
For the moment, I'm content with the approach in the patch you posted.
regards, tom lane