Re: AllocSetContextCreate changes breake extensions
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Gierth <andrew@tao11.riddles.org.uk>
Cc: Andres Freund <andres@anarazel.de>, pgsql-hackers@postgresql.org,
Christoph Berg <cb@df7cb.de>
Date: 2018-12-02T16:33:24Z
Lists: pgsql-hackers
Andrew Gierth <andrew@tao11.riddles.org.uk> writes: > "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes: > With this change, there is no reason for anybody to call > AllocSetContextCreateExtended directly, so in HEAD I renamed it to > except there IS such a reason: if you need (as I do in pl/lua) to wrap > the call in a catch block, inside a function which takes the name and so > on as a parameter, then you have no option but to do so (since using the > macro errors out on the non-const parameter). I'm kind of unimpressed by your example, because you're deliberately breaking the safety check the macro sets out to provide. With code structure like this, it's impossible to be sure that what was passed to the wrapper function is actually a constant string. You'd be better off using the workaround the comment suggests, which is to just pass "" to AllocSetContextCreate and then use MemoryContextSetIdentifier to copy the passed string. > At least let's revert the pointless name change. I don't think it's entirely pointless: it's keeping the "Extended" name available for possible future use. If I revert, what name are we going to use when we really do need an API-incompatible version of AllocSetContextCreate? regards, tom lane
Commits
-
Back-patch addition of the ALLOCSET_FOO_SIZES macros.
- ec185747a46e 9.4.20 landed
- 1245561df490 9.5.15 landed
- 01187f32cd61 9.3.25 landed
-
Simplify use of AllocSetContextCreate() wrapper macro.
- 3d059655be7d 11.0 landed
- 13cd7209f794 12.0 landed
-
Rethink MemoryContext creation to improve performance.
- 9fa6f00b1308 11.0 cited