From: | Eric Hanson <eric(at)aquameta(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Peter Eisentraut <peter(at)eisentraut(dot)org>, pgsql-docs(at)lists(dot)postgresql(dot)org |
Subject: | Re: "name" vs "alias" in datatype table |
Date: | 2023-11-29 18:27:08 |
Message-ID: | CACA6kxhTPh8-a2=kKbXfFx38H9bsGht-hWGA730uaBM3BvAE6Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-docs |
On Wed, Nov 29, 2023 at 10:26 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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
>
I like the preferred name being the preferred name and focal point, as most
users aren't going to much care about internal type names. For "int",
"decimal" and "char", how about a "shorthand" column? Wouldn't be too
wide. So:
1. Name
2. Shorthand
3. Internal name
4. Description
And maybe a paragraph at the top explaining that types have multiple names
that can be used interchangeably, but users are encouraged to use the
standard names for beauty and clarity.
I could also see splitting this into two tables. First just a) Name,
Description. Second, a paragraph about internal names and such, then b)
Name, Shorthand, Internal Name, Description. That way for quick reference
people will just see a simple table that gets 90% of readers what they need.
From | Date | Subject | |
---|---|---|---|
Next Message | Euler Taveira | 2023-11-29 18:39:07 | Re: An inconsistency in the documentation about full text search |
Previous Message | Alvaro Herrera | 2023-11-29 16:42:54 | Re: "name" vs "alias" in datatype table |