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

From: jian he <jian(dot)universality(at)gmail(dot)com>
To: Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>
Cc: John Naylor <johncnaylorls(at)gmail(dot)com>, Alexander Korotkov <aekorotkov(at)gmail(dot)com>, Steve Chavez <steve(at)supabase(dot)io>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Add pg_basetype() function to obtain a DOMAIN base type
Date: 2024-02-18 01:30:44
Message-ID: CACJufxGEZYpiObCaXfD6yCYJ-JW3GS7bcViun+PfEKFu7uC_MQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Feb 18, 2024 at 2:49 AM Tomas Vondra
<tomas(dot)vondra(at)enterprisedb(dot)com> wrote:
>
> An alternative approach would be modifying pg_typeof() to optionally
> determine the base type, depending on a new argument which would default
> to "false" (i.e. the current behavior).
>
> So you'd do
>
> SELECT pg_typeof(x);
>
> or
>
> SELECT pg_typeof(x, false);
>
> to get the current behavior, or and
>
> SELECT pg_typeof(x, true);
>
> to determine the base type.
>
> Perhaps this would be better than adding a new function doing almost the
> same thing as pg_typeof(). But I haven't tried, maybe it doesn't work
> for some reason, or maybe we don't want to do it this way ...
>

pg_typeof is quite hot.
getting the base type of a domain is niche.

changing pg_typeof requires extra effort to make it compatible with
previous behavior.
bundling it together seems not worth it.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message zwj 2024-02-18 01:37:39 bug report: some issues about pg_15_stable(8fa4a1ac61189efffb8b851ee77e1bc87360c445)
Previous Message Tomas Vondra 2024-02-18 01:28:06 Re: Add last_commit_lsn to pg_stat_database