Request a Demo
Home   >   mailing lists

Re: Do we need use more meaningful variables to replace 0 in catalog head files? - Mailing list pgsql-hackers

From Hao Lee
Subject Re: Do we need use more meaningful variables to replace 0 in catalog head files?
Date
Msg-id CAGoxFiE7USG0tG0eK4eXsm0x_WwbgCaZ9tuJu4_XazLYSAYu_g@mail.gmail.com
Whole thread
In response to Re: Do we need use more meaningful variables to replace 0 in catalog head files?  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Do we need use more meaningful variables to replace 0 in catalog head files?
List pgsql-hackers
Tree view
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@gmail.com> wrote:
On Mon, Nov 7, 2016 at 9:10 PM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> On Tue, Nov 8, 2016 at 10:57 AM, Hao Lee <mixtrue@gmail.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

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: WIP: About CMake v2
Next
From: Michael Paquier
Date:
Subject: Re: Bug in comparison of empty jsonb arrays to scalars