On Wed, Mar 18, 2020 at 02:29:17PM -0300, Alvaro Herrera wrote: > I don't think it will, directly; debian.codesearch.net says only patroni > and slony1-2 contain the "parse_real", and both have their own > implementations (patroni is Python anyway). I didn't find any > relopt_real anywhere.
Reloptions in general are not used much in extensions, and one could assume that reloptions of type real (well, double) are even less. > However, if we were to rename DefineCustomRealVariable() to match, that > would no doubt hurt a lot of people. We also have GucRealCheckHook and > GucRealAssignHook typedefs, but those appear to hit no Debian package. > (In guc.c, the fallout rabbit hole goes pretty deep, but that seems well > localized.) I make use of this API myself, for some personal stuff, and even some internal company stuff. And I am ready to bet that it is much more popular than its reloption cousin mainly for bgworkers. Hence a rename would need a compatibility layer remaining around. Honestly, I am not sure that a rename is worth it. > I don't think the last pg13 CF is when to be spending time on this, > though. Indeed. Do any of you have any arguments against the patch proposed upthread switching "float4" to "floating point" then? Better be sure.. -- Michael
signature.asc
Description: PGP signature
