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 →
-
Add pg_basetype() function to extract a domain's base type.
- b154d8a6d0e5 17.0 landed