Horton

Re: Cache lookup errors with functions manipulation object addresses

Alvaro Herrera <alvherre@2ndquadrant.com>

View thread View on postgr.es
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Michael Paquier <michael.paquier@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>, PostgreSQL mailing lists <pgsql-hackers@postgresql.org>, Moshe Jacobson <moshe@neadwerx.com>
Date: 2017-07-20T16:26:23Z
Lists: pgsql-hackers 
Michael Paquier wrote:
> On Thu, Jul 20, 2017 at 4:04 PM, Alvaro Herrera
> <alvherre@2ndquadrant.com> wrote:
> > I think the addition of checks everywhere for NULL return is worse.
> > Let's add a missing_ok flag instead, so that most callers can just trust
> > that they get a non null value if they don't want to deal with that
> > case.
> 
> If you want to minimize the diffs or such a patch, we could as well
> have an extended version of those APIs. I don't think that for the
> addition of one argument like a missing_ok that's the way to go, but
> some people may like that to make this patch less intrusive.

I think minimizing API churn is worthwhile in some cases but not all.
These functions seem fringe enough that not having an API-compatible
version is unnecessary.  But that's just my opinion.

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

Commits

  1. Eliminate cache lookup errors in SQL functions for object addresses

  2. Refactor routines for name lookups of procedures and operators

  3. Add new flag to format_type_extended() to get NULL for undefined type

  4. Introduce new extended routines for FDW and foreign server lookups

  5. Refactor routines for subscription and publication lookups

  6. get_relid_attribute_name is dead, long live get_attname

  7. Tweak parser so that there is a defined representation for datatypes