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