From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
---|---|
To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
Cc: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Aleksander Alekseev <a(dot)alekseev(at)postgrespro(dot)ru>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] Cache lookup errors with functions manipulation object addresses |
Date: | 2018-02-12 22:57:34 |
Message-ID: | 20180212225734.inxlrlsglmjspoum@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Michael Paquier wrote:
> On Fri, Jan 12, 2018 at 11:01:59AM +0900, Michael Paquier wrote:
> > Thanks Mr. Robot and Thomas for the reminder. Attached is an updated
> > patch set taking care of those warnings, 0002 and 0004 being impacted.
>
> The last patch set has rotten enough for git am to complain (not patch
> -p1), so attached is a new set.
Pushed 0001, which was easy enough to deal with. I think 0002 and 0003
should be changed similarly: the elog(ERROR) code should be inside "if"
and the "return NULL" case the straight path, rather than the other way
around. That seems more robust than the compiler relying on knowledge
that elog(ERROR) does not return.
As far as format_type_extended() is concerned, IMO we've gone far enough
with the number of variants of format_type(). Making the function
public makes sense to me, but let's add a bits32 flags argument instead
of exposing the messy set of booleans. We can add compatibility
wrappers for the flag combinations most used in core code, and maybe
take the opportunity phase out the uncommon ones.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2018-02-12 23:04:01 | Re: Minor version upgrades and extension packaging |
Previous Message | Tom Lane | 2018-02-12 22:03:19 | Re: Using scalar function as set-returning: bug or feature? |