Re: type of some table storage params on doc

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Atsushi Torikoshi <atorik(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: type of some table storage params on doc
Date: 2020-03-18 16:51:44
Message-ID: 20200318165144.GA21584@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2020-03-18 16:54:09 Re: Auxiliary Processes and MyAuxProc
Previous Message Tom Lane 2020-03-18 16:50:18 Re: Small docs bugfix: make it clear what can be used in UPDATE FROM and DELETE USING