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

On 2/17/24 01:57, jian he wrote:
> On Sat, Feb 17, 2024 at 2:16 AM Tomas Vondra
> <tomas.vondra@enterprisedb.com> wrote:
>>
>> Hi,
>>
>> On 1/2/24 01:00, jian he wrote:
>>> On Mon, Dec 4, 2023 at 5:11 PM John Naylor <johncnaylorls@gmail.com> wrote:
>>>>
>>>> On Thu, Sep 28, 2023 at 12:22 AM Alexander Korotkov
>>>> <aekorotkov@gmail.com> wrote:
>>>>> The one thing triggering my perfectionism is that the patch does two
>>>>> syscache lookups instead of one.
>>>>
>>>> For an admin function used interactively, I'm not sure why that
>>>> matters? Or do you see another use case?
>>>
>>> I did a minor refactor based on v1-0001.
>>> I think pg_basetype should stay at "9.26.4. System Catalog Information
>>> Functions".
>>> So I placed it before pg_char_to_encoding.
>>> Now functions listed on "Table 9.73. System Catalog Information
>>> Functions" will look like alphabetical ordering.
>>> I slightly changed the src/include/catalog/pg_proc.dat.
>>> now it looks like very similar to pg_typeof
>>>
>>> src6=# \df pg_typeof
>>>                            List of functions
>>>    Schema   |   Name    | Result data type | Argument data types | Type
>>> ------------+-----------+------------------+---------------------+------
>>>  pg_catalog | pg_typeof | regtype          | "any"               | func
>>> (1 row)
>>>
>>> src6=# \df pg_basetype
>>>                             List of functions
>>>    Schema   |    Name     | Result data type | Argument data types | Type
>>> ------------+-------------+------------------+---------------------+------
>>>  pg_catalog | pg_basetype | regtype          | "any"               | func
>>> (1 row)
>>>
>>> v2-0001 is as is in the first email thread, 0002 is my changes based on v2-0001.
>>
>>
>> I think the patch(es) look reasonable, so just a couple minor comments.
>>
>> 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).

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


regards

-- 
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company