Re: Rethinking MemoryContext creation

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, Dec 11, 2017 at 11:59 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> writes:
>>> On 12/11/2017 05:27 PM, Tom Lane wrote:
>>>> However, unless we want to run around and touch all the ~ 150 calls
>>>> with constant arguments, we'd have to set things up so that the default
>>>> behavior for AllocSetContextCreate is to not copy. This risks breaking
>>>> callers in extensions. Not entirely sure if it's worth that --- any
>>>> thoughts?

>>> I don't think silently breaking extensions is particularly attractive
>>> option, so I guess we'll have to run around and tweak the ~150 calls.

> I also don't think silently breaking extensions is a terribly big deal
> in this case. It seems likely that most extensions use static names
> just as most of our internal stuff does. I'm going to guess that the
> number of extensions that will actually break as a result of a change
> in this area is probably very small - conceivably zero, and likely
> less than five. I don't think we should be willing to uglify the core
> code too much for that level of breakage.

[ thinks... ] If we wanted to go that way, one thing we could do to
help extension authors (and ourselves) is to define the proposed
AllocSetContextCreate macro to include

StaticAssertExpr(__builtin_constant_p(name))

on compilers that have __builtin_constant_p. Now, that only helps
people using gcc and gcc-alikes, but that's a large fraction of
developers I should think. (I tested this and it does seem to
correctly recognize string literals as constants.)

regards, tom lane