Re: type of some table storage params on doc - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: type of some table storage params on doc
Date
Msg-id 20200319024124.GQ214947@paquier.xyz
Whole thread Raw
In response to Re: type of some table storage params on doc  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: type of some table storage params on doc  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
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

Attachment

pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: pg_stat_progress_basebackup - progress reporting forpg_basebackup, in the server side
Next
From: Fujii Masao
Date:
Subject: Re: pg_stat_progress_basebackup - progress reporting forpg_basebackup, in the server side