From: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | jian he <jian(dot)universality(at)gmail(dot)com>, 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-17 23:29:45 |
Message-ID: | 23ef970c-b2e5-40f4-a26e-a0a58b9ce175@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2/17/24 20:20, Tom Lane wrote:
> Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> writes:
>> On 2/17/24 01:57, jian he wrote:
>>> On Sat, Feb 17, 2024 at 2:16 AM Tomas Vondra
>>> <tomas(dot)vondra(at)enterprisedb(dot)com> wrote:
>>>> 1) We already have pg_typeof() function, so maybe we should use a
>>>> similar naming convention pg_basetypeof()?
>
>>> I am ok with pg_basetypeof.
>
>> 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).
>
> Forgive me for not having read the thread, but I wonder why we want
> this to duplicate the functionality of pg_typeof() at all. My first
> reaction to the requirement given in the thread subject is to write
> a function that takes a type OID and returns another type OID
> (or the same OID, if it's not a domain). If you want to determine
> the base type of some namable object, you could combine the functions
> like "basetypeof(pg_typeof(x))". But ISTM there are other use cases
> where you'd have a type OID. Then having to construct an object to
> apply a pg_typeof-like function to would be difficult.
>
Yeah, I think you're right - the initial message does actually seem to
indicate it needs to pass type "type OID" to the function, not some
arbitrary expression (and then process a type of it). So modeling it per
pg_typeof(any) would not even work.
Also, now that I looked at the v2 patch again, I see it only really
tweaked the pg_proc.dat entry, but the code still does PG_GETARG_OID (so
the "any" bit is not really correct).
> I don't have an immediate proposal for exactly what to call such a
> function, but naming it by analogy to pg_typeof would be questionable.
>
Are you objecting to the pg_basetypeof() name, or just to it accepting
"any" argument? I think pg_basetypeof(regtype) would work ...
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2024-02-18 00:29:08 | Re: date_trunc function in interval version |
Previous Message | Tomas Vondra | 2024-02-17 23:10:44 | Re: linux cachestat in file Readv and Prefetch |