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.
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 |