From: Tom Lane <tgl@sss.pgh.pa.us>
To: Eric Hanson <eric@aquameta.com>
cc: Peter Eisentraut <peter@eisentraut.org>, pgsql-docs@lists.postgresql.org
Subject: Re: "name" vs "alias" in datatype table
In-reply-to: 
 <CACA6kxixrAJoTt7MpUtbuT++JDifWiPQCLJ5YzFzpML2Pm-WYQ@mail.gmail.com>
References: <170077271331.398198.16997446522206025709@wrigleys.postgresql.org>
 <83419ce9-e2ba-46e9-aaff-f6bbe448a327@eisentraut.org>
 <CACA6kxjoGV+QxpvBa20Vdu+of3gxATWuot8FLSa1Sm2BfikN4w@mail.gmail.com>
 <CACA6kxixrAJoTt7MpUtbuT++JDifWiPQCLJ5YzFzpML2Pm-WYQ@mail.gmail.com>
Comments: In-reply-to Eric Hanson <eric@aquameta.com>
	message dated "Wed, 29 Nov 2023 09:16:57 -0600"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <308439.1701275206.1@sss.pgh.pa.us>
Date: Wed, 29 Nov 2023 11:26:46 -0500
Message-ID: <308440.1701275206@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/308440.1701275206%40sss.pgh.pa.us>
Precedence: bulk

Eric Hanson <eric@aquameta.com> writes:
> The larger point being, the "name" vs "alias" paradigm presented in this
> table does not accurately represent PostgreSQL, and conveys an inaccurate
> picture of the relationship between type names.  int4 is not an "alias".

I agree that this could be improved, mainly because it's far from
clear what the internal name of each type is (and there's at least
one case where the internal name is not shown at all).

I could see splitting this into three columns:

1. Preferred name (the standard's name, if it's a standard type)

2. Internal name (pg_type.typname), perhaps only if different from #1

3. Other aliases

However, the table is already pretty wide and so adding another
column might create formatting issues.

AFAICS the only candidates for "other aliases" are char, int,
and decimal.  Maybe we could handle those another way than reserving
a table column for them?  We could give them their own table rows,
or relegate them to footnotes.

The "serial" types need a bit more reflection too, since they
aren't truly types at all: there is no matching pg_type entry.
I'm not sure they belong here.

			regards, tom lane