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

Поиск
Список
Период
Сортировка
От Hao Lee
Тема Re: Do we need use more meaningful variables to replace 0 in catalog head files?
Дата
Msg-id CAGoxFiE7USG0tG0eK4eXsm0x_WwbgCaZ9tuJu4_XazLYSAYu_g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Do we need use more meaningful variables to replace 0 in catalog head files?  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Do we need use more meaningful variables to replace 0 in catalog head files?
Список pgsql-hackers
<div dir="ltr">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
maintenancethe consistency between these catalogs and views. It's need more cares when do modifying. So that i think
thatwhether there are some more smarter approaches to make it smarter or not.  </div><div class="gmail_extra"><br
/><divclass="gmail_quote">On Wed, Nov 9, 2016 at 6:33 AM, Robert Haas <span dir="ltr"><<a
href="mailto:robertmhaas@gmail.com"target="_blank">robertmhaas@gmail.com</a>></span> wrote:<br /><blockquote
class="gmail_quote"style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, Nov 7,
2016at 9:10 PM, Michael Paquier<br /> <<a href="mailto:michael.paquier@gmail.com">michael.paquier@gmail.com</a>>
wrote:<br/> > On Tue, Nov 8, 2016 at 10:57 AM, Hao Lee <<a
href="mailto:mixtrue@gmail.com">mixtrue@gmail.com</a>>wrote:<br /> >> It's a tedious work to figure out these
numbersreal meaning. for example,<br /> >> if i want to know the value of '71'  represent what it is. I should go
back<br/> >> to refer to definition of pg_class struct. It's a tedious work and it's not<br /> >>
maintainableor readable.  I THINK WE SHOULD USE a meaningful variable<br /> >> instead of '71'. For Example:<br
/>>><br /> >> #define PG_TYPE_RELTYPE 71<br /> ><br /> > You'd need to make <a
href="http://genbki.pl"rel="noreferrer" target="_blank">genbki.pl</a> smarter regarding the way to associate<br /> >
thosevariables with the defined variables, greatly increasing the<br /> > amount of work it is doing as well as its
maintenance(see for PGUID<br /> > handling for example). I am not saying that this is undoable, just<br /> > that
thecomplexity may not be worth the potential readability gains.<br /><br /></span>Most of these files don't have that
manyentries, and they're not<br /> modified that often.  The elephant in the room is pg_proc.h, which is<br /> huge,
frequently-modified,and hard to decipher.  But I think that's<br /> going to need more surgery than just introducing
namedconstants -<br /> which would also have the downside of making the already-long lines<br /> even longer.<br
/><spanclass="HOEnZb"><font color="#888888"><br /> --<br /> Robert Haas<br /> EnterpriseDB: <a
href="http://www.enterprisedb.com"rel="noreferrer" target="_blank">http://www.enterprisedb.com</a><br /> The Enterprise
PostgreSQLCompany<br /></font></span></blockquote></div><br /></div> 

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: WIP: About CMake v2
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Bug in comparison of empty jsonb arrays to scalars