Re: Add pg_basetype() function to obtain a DOMAIN base type
От | Tomas Vondra |
---|---|
Тема | Re: Add pg_basetype() function to obtain a DOMAIN base type |
Дата | |
Msg-id | d12ce3b5-03dc-4e3d-8b1b-47161f647110@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: Add pg_basetype() function to obtain a DOMAIN base type (jian he <jian.universality@gmail.com>) |
Ответы |
Re: Add pg_basetype() function to obtain a DOMAIN base type
(Tom Lane <tgl@sss.pgh.pa.us>)
Re: Add pg_basetype() function to obtain a DOMAIN base type (jian he <jian.universality@gmail.com>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления:
Предыдущее
От: Pavel LuzanovДата:
Сообщение: Re: Things I don't like about \du's "Attributes" column