Re: type of some table storage params on doc

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

On 2020-Mar-18, Tom Lane wrote:

> Alvaro Herrera <alvherre(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message James Coleman 2020-03-18 17:33:07 Re: Berserk Autovacuum (let's save next Mandrill)
Previous Message Pavel Stehule 2020-03-18 17:22:09 Re: proposal: new polymorphic types - commontype and commontypearray