Brendan Jurd wrote: > On Nov 9, 2007 3:17 AM, Bruce Momjian <[EMAIL PROTECTED]> wrote: > > We want patch submitters to spend their time on patches, not learning > > our style. The fact is that pgindent is a silver bullet in some ways. > > Well there's a lot of support for the idea of pgindent being good > enough to establish a consistent coding style. I personally think a > much higher target for consistency would be worth pursuing, but I can > tell when I'm outgunned. > > Maybe it would be more productive to drop the topic of code style (as > in whitespace/formatting) and stick to talking about code style (as in > GETARG). > > I've suggested that some more information on using ereport effectively > might be at home in such a list. Perhaps some advice about working > with varlenas (which macros you should use in given situations, > differentiating toasted and detoasted). > > Are there any items which patch reviewers find themselves repeating to > several different developers? Things that follow the form "Don't use > $foo, use $bar", or "We don't do $x anymore, do $y instead"? These > are the sorts of items that would really benefit from publication.
I can't think of anything that isn't already in the developer's FAQ. > > My major contention is that any list is going to be very details and > > hard to read, and no one has put up a list disputing that. > > > > This complaint still puzzles me. Why would it be hard to read? > Wouldn't that have more to do with the way it is presented than what > it contains? If it turns out to be hard to read, that's just an > indication that it needs to be better formatted. This isn't > superstring theory. It's just some guidelines on how to write good > Postgres code. It is going to be lots of minutia that is going to be very unintersting and saying just follow the surrounding code is a better use of their time rather than reading a list. > Even if it were hard to read, reading a difficult document is pretty > much guaranteed to take less time than waiting on a full review cycle, > then reworking, recompiling, retesting and resubmitting your patch. We just don't see that happening much in practice. -- Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match