On 9 November 2016 at 10:20, Hao Lee <mixt...@gmail.com> wrote: > 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 <robertmh...@gmail.com> wrote: >> >> On Mon, Nov 7, 2016 at 9:10 PM, Michael Paquier >> <michael.paqu...@gmail.com> wrote: >> > On Tue, Nov 8, 2016 at 10:57 AM, Hao Lee <mixt...@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.
I'd be pretty happy to see pg_proc.h in particular replaced with some pg_proc.h.in with something sane doing the preprocessing. It's a massive pain right now. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
