Re: Add pg_basetype() function to obtain a DOMAIN base type

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alexander Korotkov <aekorotkov@gmail.com>
Cc: jian he <jian.universality@gmail.com>, Tomas Vondra <tomas.vondra@enterprisedb.com>, John Naylor <johncnaylorls@gmail.com>, Steve Chavez <steve@supabase.io>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2024-03-18T15:43:51Z
Lists: pgsql-hackers
Alexander Korotkov <aekorotkov@gmail.com> writes:
> On Mon, Mar 18, 2024 at 2:01 AM jian he <jian.universality@gmail.com> wrote:
>> `
>> Datum
>> pg_basetype(PG_FUNCTION_ARGS)
>> {
>> 	Oid oid;
>> 
>> 	oid =  get_fn_expr_argtype(fcinfo->flinfo, 0);
>> 	PG_RETURN_OID(getBaseType(oid));
>> }
>> `

> Looks good to me.  But should it be named pg_basetypeof()?

I still don't like this approach.  It forces the function to be
used in a particular way that's highly redundant with pg_typeof.
I think we'd be better off with

pg_basetype(PG_FUNCTION_ARGS)
{
	Oid typid = PG_GETARG_OID(0);

	PG_RETURN_OID(getBaseType(typid));
}

The use-case that the other definition handles would be implemented
like

	pg_basetype(pg_typeof(expression))

but there are other use-cases.  For example, if you want to know
the base types of the columns of a table, you could do something
like

select attname, pg_basetype(atttypid) from pg_attribute
  where attrelid = 'foo'::regclass order by attnum;

but that functionality is simply not available with the other
definition.

Perhaps there's an argument for providing both things, but that
feels like overkill to me.  I doubt that pg_basetype(pg_typeof())
is going to be so common as to need a shorthand.

			regards, tom lane



Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Add pg_basetype() function to extract a domain's base type.