From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
cc: Daniel Gustafsson <daniel@yesql.se>,
        Peter Eisentraut <peter.eisentraut@2ndquadrant.com>,
        pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: pgindent vs dtrace on macos
In-reply-to: <20200921190804.GA2817@alvherre.pgsql>
References: <20200921190804.GA2817@alvherre.pgsql>
Comments: In-reply-to Alvaro Herrera <alvherre@2ndquadrant.com>
	message dated "Mon, 21 Sep 2020 16:08:04 -0300"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1023611.1600716072.1@sss.pgh.pa.us>
Date: Mon, 21 Sep 2020 15:21:12 -0400
Message-ID: <1023612.1600716072@sss.pgh.pa.us>
Precedence: bulk

Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> On 2020-Sep-21, Tom Lane wrote:
>> Here's a proposed patch to fix it that way.

> pgtypes_numeric.h still contains
> typedef struct
> {
> } numeric;

> ... isn't this more likely to create a typedef entry than merely a
> function name?

Well, yeah, it *is* a typedef.  My proposal is to rename the C function
to avoid the conflict, rather than renaming the typedef.  Given the
small number of direct calls (none), that's a lot less work.  Also,
I think pgtypes_numeric.h is exposed to ecpg client code, so changing
that typedef's name could be quite problematic.

			regards, tom lane