Re: Another modest proposal for docs formatting: catalog descriptions

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-docs(at)lists(dot)postgresql(dot)org, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Another modest proposal for docs formatting: catalog descriptions
Date: 2020-05-05 05:52:08
Message-ID: alpine.DEB.2.22.394.2005050743340.175044@pseudo
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-docs pgsql-hackers


Hello Tom,

> oid oid
> Row identifier
>
> adrelid oid (references pg_class.oid)
> The table this column belongs to
>
> adnum int2 (references pg_attribute.attnum)
> The number of the column
>
> adbin pg_node_tree
> The column default value, in nodeToString() representation. Use
> pg_get_expr(adbin, adrelid) to convert it to an SQL expression.
>
> Thoughts?

+1

My 0.02€: I'm wondering whether the description could/should match SQL
syntax, eg:

oid OID
adrelid OID REFERENCES pg_class(oid)
adnum INT2 REFERENCES pg_attribute(attnum)

Or maybe just uppercase type names, especially when repeated?

oid OID
adrelid OID (references pg_class.oid)
adnum INT2 (references pg_attribute.attnum)

I guess that reference targets would still be navigable.

--
Fabien.

In response to

Responses

Browse pgsql-docs by date

  From Date Subject
Next Message Jürgen Purtz 2020-05-05 10:20:44 Re: Documentation - chapter 52, system catalogs
Previous Message Michael Paquier 2020-05-05 05:17:45 Re: Roles for pg_basebackup

Browse pgsql-hackers by date

  From Date Subject
Next Message Julien Rouhaud 2020-05-05 06:10:54 Re: PG 13 release notes, first draft
Previous Message Pavel Stehule 2020-05-05 05:46:34 Re: PG 13 release notes, first draft