Re: Lessons from commit fest
От | Tom Lane |
---|---|
Тема | Re: Lessons from commit fest |
Дата | |
Msg-id | 1544.1208477456@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Lessons from commit fest (Gregory Stark <stark@enterprisedb.com>) |
Ответы |
Re: Lessons from commit fest
Re: Lessons from commit fest |
Список | pgsql-hackers |
Gregory Stark <stark@enterprisedb.com> writes: > "Tom Lane" <tgl@sss.pgh.pa.us> writes: >> That would certainly be better than the current approach, since >> presumably it would cover not only Windows but the other >> conditionally-compiled stuff that Bruce chooses not to compile on >> his own machine. > It would, as someone said, rock. But it wouldn't really address the ability of > a developer to run pgindent on code he's about to send in, since it wouldn't > have any typedefs that developer just created. Well, that list is just a simple text file listing typedef names, so it'd hardly be difficult to add your own to the list. >> I still wish we could build the list directly from the source code, >> but I have no suggestions for tools that would do it. > If we wanted to do that I have a few questions: > 1) I take it we feel safe guaranteeing that we won't use any fancy macros > inside typedefs. So no '#define pgtype(x) _pg_##x' or anythin like that. Hmm ... we are fairly crawling with struct tags built that way: /* Introduces a catalog's structure definition */ #define CATALOG(name,oid) typedef struct CppConcat(FormData_,name) but offhand I can't think of any actual typedef names built with ##. Does indent need a preset list of struct tags? Seems that would be stupid ... > 2) How much information do we need about the typedefs? Just their name? Right. > 3) How would this work with typedefs which come from system or library > includes? Ouch, that's a real good point. Maybe a certain amount of platform dependence is inevitable. regards, tom lane
В списке pgsql-hackers по дате отправления: