Brendan Jurd wrote:
> On Nov 9, 2007 3:17 AM, Bruce Momjian <bruce@momjian.us> 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 <bruce@momjian.us> http://momjian.us EnterpriseDB
http://postgres.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
