Re: Lessons from commit fest - Mailing list pgsql-hackers

From Gregory Stark
Subject Re: Lessons from commit fest
Date
Msg-id 87od88avvu.fsf@oxford.xeocode.com
Whole thread Raw
In response to Re: Lessons from commit fest  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Lessons from commit fest  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
"Tom Lane" <tgl@sss.pgh.pa.us> writes:

> Andrew Dunstan <andrew@dunslane.net> writes:
>> I have been thinking of pursuing your suggestion of having it as a 
>> buildfarm option. We could provide a SOAP interface to collect the 
>> typedefs and then consolidate them and put them in CVS. We could even do 
>> it per release. That would include Windows, although only MinGW, not 
>> MSVC, which doesn't have objdump.
>
> 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.

> 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.
 

2) How much information do we need about the typedefs? Just their name?

3) How would this work with typedefs which come from system or library  includes?

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com Get trained by Bruce Momjian - ask me about
EnterpriseDB'sPostgreSQL training!
 


pgsql-hackers by date:

Previous
From: PFC
Date:
Subject: Re: Plan targetlists in EXPLAIN output
Next
From: Gregory Stark
Date:
Subject: Re: RFD: hexstring(n) data type