On 2/17/24 20:20, Tom Lane wrote:
> Tomas Vondra <tomas.von...@enterprisedb.com> writes:
>> On 2/17/24 01:57, jian he wrote:
>>> On Sat, Feb 17, 2024 at 2:16 AM Tomas Vondra
>>> <tomas.von...@enterprisedb.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
