Re: AllocSetContextCreate changes breake extensions - Mailing list pgsql-hackers

From Andres Freund
Subject Re: AllocSetContextCreate changes breake extensions
Date
Msg-id 20181012175655.wl4hh475ehthoohi@alap3.anarazel.de
Whole thread Raw
In response to Re: AllocSetContextCreate changes breake extensions  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: AllocSetContextCreate changes breake extensions  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 2018-10-12 13:51:53 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > But can't we just do something like:
> 
> > #if defined(HAVE__BUILTIN_CONSTANT_P) && defined(HAVE__VA_ARGS)
> > #define AllocSetContextCreate(parent, name, ...) \
> >     (StaticAssertExpr(__builtin_constant_p(name), \
> >                       "memory context names must be constant strings"), \
> >      AllocSetContextCreateExtended(parent, name, __VA_ARGS__))
> > #else
> > #define AllocSetContextCreate \
> >     AllocSetContextCreateExtended
> > #endif
> 
> > The set of compilers that have __builtin_constant_p and not vararg
> > macros got to be about empty.
> 
> Yeah, fair point, and anyway we don't need the StaticAssert to exist
> everywhere.  I'll make it so.

Cool.


> Shall we also backpatch the ALLOCSET_*_SIZES macros as Christoph
> suggested?  I'm not convinced of the usefulness of that, since
> extensions would still have to cope with them not being present
> when building against existing minor releases.

I'd do so. Many extensions are fine just building against a relatively
new minor release. Won't help extension authors in the next few months,
but after that...

Greetings,

Andres Freund


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: AllocSetContextCreate changes breake extensions
Next
From: Andres Freund
Date:
Subject: Re: Multi-insert into a partitioned table with before insert rowtrigger causes server crash on latest HEAD