Re: Do we need use more meaningful variables to replace 0 in catalog head files?

yes, i agree with you. These catalogs are not modified often. As your said,
the pg_proc modified often, therefore, there are another issues, the
dependency between these system catalogs and system views. it's hard to
gain maintenance the consistency between these catalogs and views. It's
need more cares when do modifying. So that i think that whether there are
some more smarter approaches to make it smarter or not.

On Wed, Nov 9, 2016 at 6:33 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Mon, Nov 7, 2016 at 9:10 PM, Michael Paquier
> <michael(dot)paquier(at)gmail(dot)com> wrote:
> > On Tue, Nov 8, 2016 at 10:57 AM, Hao Lee <mixtrue(at)gmail(dot)com> wrote:
> >> It's a tedious work to figure out these numbers real meaning. for
> example,
> >> if i want to know the value of '71' represent what it is. I should go
> back
> >> to refer to definition of pg_class struct. It's a tedious work and it's
> not
> >> maintainable or readable. I THINK WE SHOULD USE a meaningful variable
> >> instead of '71'. For Example:
> >>
> >> #define PG_TYPE_RELTYPE 71
> >
> > You'd need to make genbki.pl smarter regarding the way to associate
> > those variables with the defined variables, greatly increasing the
> > amount of work it is doing as well as its maintenance (see for PGUID
> > handling for example). I am not saying that this is undoable, just
> > that the complexity may not be worth the potential readability gains.
>
> Most of these files don't have that many entries, and they're not
> modified that often. The elephant in the room is pg_proc.h, which is
> huge, frequently-modified, and hard to decipher. But I think that's
> going to need more surgery than just introducing named constants -
> which would also have the downside of making the already-long lines
> even longer.
>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>