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

From Alvaro Herrera
Subject Re: type of some table storage params on doc
Date
Msg-id 20200318172917.GA24682@alvherre.pgsql
Whole thread Raw
In response to Re: type of some table storage params on doc  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: type of some table storage params on doc  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
On 2020-Mar-18, Tom Lane wrote:

> Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> > Ah, I hadn't checked -- I was taking the function and struct names at
> > face value, but it turns out that they're lies as well -- parse_real,
> > relopt_real all parsing/storing doubles *is* confusing.
> 
> Yeah, that's certainly true.  I wonder if we could rename them
> without causing a lot of pain for extensions?

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.

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 don't think the last pg13 CF is when to be spending time on this,
though.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: proposal: new polymorphic types - commontype and commontypearray
Next
From: James Coleman
Date:
Subject: Re: Berserk Autovacuum (let's save next Mandrill)