Re: type of some table storage params on doc

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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-19 02:41:24
Message-ID: 20200319024124.GQ214947@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2020-03-19 02:45:36 Re: pg_stat_progress_basebackup - progress reporting for pg_basebackup, in the server side
Previous Message Alvaro Herrera 2020-03-19 02:38:29 Re: pg_stat_progress_basebackup - progress reporting for pg_basebackup, in the server side