On 2020-Mar-18, Michael Paquier wrote:
> On Mon, Mar 16, 2020 at 11:07:37AM +0900, Atsushi Torikoshi wrote:
> > As far as I read the reloptions.c, autovacuum_vacuum_cost_delay,
> > autovacuum_vacuum_scale_factor and autovacuum_analyze_scale_factor
> > are the members of relopt_real, so their type seems the same, real.
>
> In this case, the parsing uses parse_real(), which is exactly the same
> code path as what real GUCs use.
>
> > But the manual about storage parameters[1] says two of their type
> > are float4 and the other is floating point.
> >
> > I think using float4 on storage parameters[1] are not consistent
> > so far, how about changing these parameters type from float4 to
> > floating point if there are no specific reasons using float4?
>
> That's a good idea, so I am fine to apply your patch as float4 is a
> data type. However, let's see first if others have more comments or
> objections.
Hmm. So unadorned 'floating point' seems to refer to float8; you have
to use float(24) in order to get a float4. The other standards-mandated
name for float4 seems to be REAL. (I had a look around but was unable
to figure out whether the standard mandates exact bit widths other than
the precision spec). Since they're not doubles, what about we use REAL
rather than FLOATING POINT?
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services