Re: Cache lookup errors with functions manipulation object addresses

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Daniel Gustafsson <daniel(at)yesql(dot)se>, Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Cache lookup errors with functions manipulation object addresses
Date: 2020-07-15 00:09:11
Message-ID: 20200715000911.GA8389@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jul 07, 2020 at 11:08:30AM -0400, Alvaro Herrera wrote:
g> That's a holdover from old times, when we thought functions were
> procedures. That's no longer the case.

Thanks, so "routine" it is. I have done an extra round of review of
this patch, and noticed two things:
- In getObjectDescription(), we were doing a call to get_attname() for
nothing with OCLASS_CLASS with an attribute.
- The regression test output has been changed to use \a\t to make
future diffs more readable if we add an object type that increases the
column size.

And applied the change. Thanks to everybody who took the time to look
at this code and comment about it. It took actually less than 3 years
for this threadto conclude, as it began on the 19th of July, 2017.
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Mark Dilger 2020-07-15 00:15:50 Refactoring relkind as an enum
Previous Message Tom Lane 2020-07-14 23:46:52 Re: Binary support for pgoutput plugin