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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: jian he <jian(dot)universality(at)gmail(dot)com>
Cc: Alexander Korotkov <aekorotkov(at)gmail(dot)com>, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, John Naylor <johncnaylorls(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-03-28 20:47:48
Message-ID: 3759807.1711658868@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

jian he <jian(dot)universality(at)gmail(dot)com> writes:
> trying to do it this way.
> not sure the following error message is expected.

> SELECT pg_basetype(-1);
> ERROR: cache lookup failed for type 4294967295

Yeah, that's not really OK. You could say it's fine for bogus input,
but we've found over the years that it's better for catalog inspection
functions like this to be forgiving of bad input. Otherwise,
your query can blow up in unexpected ways due to race conditions
(ie somebody just dropped the type you are interested in).

A fairly common solution to that is to return NULL for bad input,
but in this case we could just have it return the OID unchanged.

Either way though, we can't use getBaseType as-is. We could imagine
extending that function to support a "noerror"-like flag, but I
believe it's already a hot-spot and I'd rather not complicate it
further. So what I suggest doing is just duplicating the code;
there's not very much of it.

I did a little polishing of the docs and test cases too, ending
with the v7 attached. I think this is about ready to go unless
there are objections to the definition.

Not sure what I think about your 0002 proposal to extend \dD
with this. Aside from the server-version-compatibility problem,
I think it's about 90% redundant because \dD already shows
the immediate base type. The new column would only be
different in the case of nested domains, which I think are
not common. \dD's output is already pretty wide, so on the
whole I'm inclined to leave it alone.

regards, tom lane

Attachment Content-Type Size
v7-0001-Add-pg_basetype-regtype-function-to-return-the-ba.patch text/x-diff 5.0 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2024-03-28 21:19:08 Re: BitmapHeapScan streaming read user and prelim refactoring
Previous Message Robert Haas 2024-03-28 20:45:17 Re: pg_upgrade --copy-file-range