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
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 |