Date: Mon, 9 Mar 2020 18:14:44 -0300
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Pg Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: time for catalog/pg_cast.c?
Message-ID: <20200309211444.GA24535@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20200309210003.GA19992@alvherre.pgsql>
User-Agent: Mutt/1.10.1 (2018-07-13)
Precedence: bulk

On 2020-Mar-09, Alvaro Herrera wrote:

> I extracted from the latest multirange patch a bit that creates a new
> routine CastCreate() in src/backend/catalog/pg_cast.c.  It contains the
> catalog-accessing bits to create a new cast.  It seems harmless, so I
> thought I'd apply it to get rid of a couple of hunks in the large patch.

I forgot to "git add" this comment addition before sending:

/*
 * ----------------------------------------------------------------
 *		CastCreate
 *
 * Forms and inserts catalog tuples for a new cast being created.
 * Caller must have already checked privileges, and done consistency
 * checks on the given datatypes and cast function (if applicable).
 *
 * 'behavior' indicates the dependency that the new cast will have on
 * its input and output types and the cast function.
 * ----------------------------------------------------------------
 */
ObjectAddress
CastCreate(Oid sourcetypeid, Oid targettypeid, Oid funcid, char castcontext,
		   char castmethod, DependencyType behavior)


I think the only API consideration here is for 'castcontext', which we
pass here as the pg_type.h symbol, but could alternatively be passed as
CoercionContext enum values (from primnodes.h).  I think the pg_cast.h
char is okay, but maybe somebody has a different opinion.
We could also add some trivial asserts (like if procoid is not invalid,
then method is function, etc.), but it doesn't seem worth fussing too
much over.

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