Throw some low-level C scutwork at me

On Wed, Apr 29, 2009 at 01:34:19PM -0500, Andy Lester wrote:

I've got my git clone set up, a copy of GCC 4.4 (and other
compilers) at the ready, and am glad to help out on low-level scut
work. Anybody need anything done? splint? valgrind? Let me know.

Getting our Perl into shape would be Really Good(TM). :)

Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

Getting our Perl into shape would be Really Good(TM). :)

I will, but right now my #1 is getting some vi modelines in place so
we can all be using the same tab/space settings.

xoxo,
Andy

--
Andy Lester => andy@petdance.com => www.theworkinggeek.com => AIM:petdance

Andy Lester wrote:

Getting our Perl into shape would be Really Good(TM). :)

I will, but right now my #1 is getting some vi modelines in place so
we can all be using the same tab/space settings.

Hasn't that been discussed before and rejected? (For one thing, plenty
of us don't use vi)

cheers

andrew

On Thu, Apr 30, 2009 at 05:39:42PM -0400, Andrew Dunstan wrote:

Andy Lester wrote:

Getting our Perl into shape would be Really Good(TM). :)

I will, but right now my #1 is getting some vi modelines in place so
we can all be using the same tab/space settings.

Hasn't that been discussed before and rejected?

Not that I know of.

(For one thing, plenty of us don't use vi)

An emacs modeline would go in a similar spot.

Apart from those two, are there other modelines we would need?

Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

On Apr 30, 2009, at 4:39 PM, Andrew Dunstan wrote:

I will, but right now my #1 is getting some vi modelines in place
so we can all be using the same tab/space settings.

Hasn't that been discussed before and rejected? (For one thing,
plenty of us don't use vi)

For those who do use vi, it enforces proper file formatting for the
user without having to worry about local settings.

And if you're an Emacs person, you can help figure out what the
modeline should be for Emacs, and we can get that in there, too.

xoa

--
Andy Lester => andy@petdance.com => www.theworkinggeek.com => AIM:petdance

Andy Lester <andy@petdance.com> writes:

And if you're an Emacs person, you can help figure out what the
modeline should be for Emacs, and we can get that in there, too.

If you're an Emacs person, you fix it in your ~/.emacs file so that
every .c file in the Postgres tree is automatically handled with the
correct mode. Surely vi apologists can make their editor do the same.

Let me make it perfectly clear that a patch to add either vi or emacs
decoration to every file in the tree will be rejected out of hand.
We had a similar thing for awhile with the .sgml files, and got rid of
that because it sucked ...

regards, tom lane

On Fri, May 1, 2009 at 11:23 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Andy Lester <andy@petdance.com> writes:

And if you're an Emacs person, you can help figure out what the
modeline should be for Emacs, and we can get that in there, too.

If you're an Emacs person, you fix it in your ~/.emacs file so that
every .c file in the Postgres tree is automatically handled with the
correct mode.  Surely vi apologists can make their editor do the same.

Let me make it perfectly clear that a patch to add either vi or emacs
decoration to every file in the tree will be rejected out of hand.
We had a similar thing for awhile with the .sgml files, and got rid of
that because it sucked ...

For what it's worth, I agree with Tom. This sort of thing is more
annoying than useful. There are other ways to solve this problem.

Speaking of space/tab settings, one thing I'm fuzzy on is the rule for
wrapping long lines. I understand that a line that extends past 80
characters has to be wrapped, but the amount of indentation on the
continuation line doesn't appear to follow a consistent pattern - or
does it?

...Robert

Robert Haas <robertmhaas@gmail.com> writes:

Speaking of space/tab settings, one thing I'm fuzzy on is the rule for
wrapping long lines. I understand that a line that extends past 80
characters has to be wrapped, but the amount of indentation on the
continuation line doesn't appear to follow a consistent pattern - or
does it?

I tend to let emacs indent the continuation line the way it wants.
pg_indent sometimes has a slightly different theory about that, but
it usually doesn't change it enough to be a problem.

A rough rule of thumb is that pg_indent is pretty good at horizontal
whitespace decisions and absolutely terrible at vertical decisions.
Break the lines where you want them, and put blank lines where and only
where you want them, and pg_indent will clean up the rest pretty well.

Also, I don't think that 80 columns is an inviolable limit. I don't
generally like to break up error message strings just to keep the
ereport call to 80 columns, for instance. (This is partly because
I know how often it comes in handy to grep the source for particular
message strings --- and breaking the string in a random place can
defeat that.) What I do think is that the code should be easily readable
in an 80-column window. It's usually pretty obvious when a patch author
was working in a 100-or-more-column window, if you try to read it in
80 columns ...

regards, tom lane

On May 1, 2009, at 8:38 AM, Robert Haas wrote:

Speaking of space/tab settings, one thing I'm fuzzy on is the rule for
wrapping long lines. I understand that a line that extends past 80
characters has to be wrapped, but the amount of indentation on the
continuation line doesn't appear to follow a consistent pattern - or
does it?

“Perl Best Practices” recommends an indentation of 4 spaces, both for
block indentations and line continuations. Not sure what'd be best for
C, though.

Best,

David

David E. Wheeler wrote:

On May 1, 2009, at 8:38 AM, Robert Haas wrote:

Speaking of space/tab settings, one thing I'm fuzzy on is the rule for
wrapping long lines. I understand that a line that extends past 80
characters has to be wrapped, but the amount of indentation on the
continuation line doesn't appear to follow a consistent pattern - or
does it?

�Perl Best Practices� recommends an indentation of 4 spaces, both for
block indentations and line continuations. Not sure what'd be best for
C, though.

Please, let's not have a whole host of different indentation styles.
Postgres has a well established style. Let's stick to it in both perl and C.

cheers

andrew

On May 1, 2009, at 10:38 AM, Andrew Dunstan wrote:

Please, let's not have a whole host of different indentation styles.
Postgres has a well established style. Let's stick to it in both
perl and C

+1

David

On Fri, May 01, 2009 at 01:38:38PM -0400, Andrew Dunstan wrote:

David E. Wheeler wrote:

On May 1, 2009, at 8:38 AM, Robert Haas wrote:

Speaking of space/tab settings, one thing I'm fuzzy on is the rule
for wrapping long lines. I understand that a line that extends
past 80 characters has to be wrapped, but the amount of
indentation on the continuation line doesn't appear to follow a
consistent pattern - or does it?

“Perl Best Practices” recommends an indentation of 4 spaces, both
for block indentations and line continuations. Not sure what'd be
best for C, though.

Please, let's not have a whole host of different indentation styles.
Postgres has a well established style. Let's stick to it in both
perl and C.

Perl is not C, and there's no good reason to make them look the same.
We don't format SQL the same way we do C either, and that's a totally
reasonable decision.

Using idiomatic perl like this:

foreach my $element (@array) {
# clear, short, idiomatic code here
}

instead of Rube Goldberg constructs like this:

my $i;
for ($i=0; $i <= $#array; ++$i)
{
# kludges up down and sideways here
}

is a good idea because it makes it easier for Perl programmers to
maintain. It's also more efficient on the machine, for what that's
worth.

Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

On May 1, 2009, at 10:54 AM, David Fetter wrote:

foreach my $element (@array) {
# clear, short, idiomatic code here
}

instead of Rube Goldberg constructs like this:

my $i;
for ($i=0; $i <= $#array; ++$i)
{
# kludges up down and sideways here
}

is a good idea because it makes it easier for Perl programmers to
maintain. It's also more efficient on the machine, for what that's
worth.

We were only talking about indentation, David, not the use of idioms.

Best,

David

If you're an Emacs person, you fix it in your ~/.emacs file so that
every .c file in the Postgres tree is automatically handled with the
correct mode. Surely vi apologists can make their editor do the same.

Thanks for your remarkable response. I will refer to it often for
months to come. I think it tells me quite a bit about the Postgres
world.

--
Andy Lester => andy@petdance.com => www.theworkinggeek.com => AIM:petdance

On Fri, May 01, 2009 at 11:23:24AM -0400, Tom Lane wrote:

Andy Lester <andy@petdance.com> writes:

And if you're an Emacs person, you can help figure out what the
modeline should be for Emacs, and we can get that in there, too.

If you're an Emacs person, you fix it in your ~/.emacs file so that
every .c file in the Postgres tree is automatically handled with the
correct mode. Surely vi apologists can make their editor do the same.

Let me make it perfectly clear that a patch to add either vi or emacs
decoration to every file in the tree will be rejected out of hand.
We had a similar thing for awhile with the .sgml files, and got rid of
that because it sucked ...

Tom,

That was truly un-called-for. I don't care who you are or what you've
done because nobody gets to treat volunteers the way you did above.
You need to back off if you're not going to do anything helpful.

If you were wondering how our community gets a reputation for
repulsing outsiders, this is a classical example.

I'd appreciate your making an argument, if you're going to, on the
merits of the proposal at hand, rather than stooping to personal
insult. You know better.

Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

On Fri, 2009-05-01 at 12:09 -0700, David Fetter wrote:

I'd appreciate your making an argument, if you're going to, on the
merits of the proposal at hand, rather than stooping to personal
insult. You know better.

O.k. guys let's all take a breath here. We all have our favorite editors
and our favorite way of doing things. Frankly I think both emacs and vi
users are nuts. I found the light in joe years ago :). Regardless, I
agree with Tom that the idea of having decorators of any kind in source
or docs is a bad idea.

That being said, there is no reason why we can have a section of the
wiki that has .rc files for respective editors and environments that
conform to .Org coding conventions.

Peace.

Joshua D. Drake

--
PostgreSQL - XMPP: jdrake@jabber.postgresql.org
Consulting, Development, Support, Training
503-667-4564 - http://www.commandprompt.com/
The PostgreSQL Company, serving since 1997

"Joshua D. Drake" <jd@commandprompt.com> writes:

That being said, there is no reason why we can have a section of the
wiki that has .rc files for respective editors and environments that
conform to .Org coding conventions.

I think we already have that in the CVS tree - look in
src/tools/editors/. Might be out of date though.

regards, tom lane

On Fri, May 01, 2009 at 12:37:19PM -0700, Joshua D. Drake wrote:

On Fri, 2009-05-01 at 12:09 -0700, David Fetter wrote:

I'd appreciate your making an argument, if you're going to, on the
merits of the proposal at hand, rather than stooping to personal
insult. You know better.

O.k. guys let's all take a breath here.

No.

Tom screwed up, and he needs to fix it.

Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

On May 1, 2009, at 2:37 PM, Joshua D. Drake wrote:

Regardless, I
agree with Tom that the idea of having decorators of any kind in
source
or docs is a bad idea.

Why is it a bad idea? I don't understand the downside of a line or
two at the bottom of a source file.

That being said, there is no reason why we can have a section of the
wiki that has .rc files for respective editors and environments that
conform to .Org coding conventions.

I've always found it preferable to have the editors enforce the coding
standards for us, without relying on the coder do anything on his
end. I'd rather that volunteers, especially new volunteers, spend
their time and brain cycles thinking about code, not messing with
config files.

xoa

--
Andy Lester => andy@petdance.com => www.theworkinggeek.com => AIM:petdance

Joshua D. Drake wrote:

That being said, there is no reason why we can have a section of the
wiki that has .rc files for respective editors and environments that
conform to .Org coding conventions.

Look in src/tools/editors. Already there. For both emacs and vi.

cheers

andrew

Andy Lester wrote:

On May 1, 2009, at 2:37 PM, Joshua D. Drake wrote:

Regardless, I
agree with Tom that the idea of having decorators of any kind in source
or docs is a bad idea.

Why is it a bad idea? I don't understand the downside of a line or
two at the bottom of a source file.

Because it becomes one more maintenance task we don't need.

That being said, there is no reason why we can have a section of the
wiki that has .rc files for respective editors and environments that
conform to .Org coding conventions.

I've always found it preferable to have the editors enforce the coding
standards for us, without relying on the coder do anything on his
end. I'd rather that volunteers, especially new volunteers, spend
their time and brain cycles thinking about code, not messing with
config files.

FWIW I had a quick look at two other OS projects: the linux kernel and
the apache httpd server. Apache is simple - there's one vim line and no
vi lines in the whole source. The linux kernel is a mess. There are a
couple of hundred files with inconssistent mode lines. Most have none
(and there are thousands).

So we're hardly alone in not doing it the way you're suggesting.

cheers

andrew

David Fetter <david@fetter.org> writes:

That was truly un-called-for. I don't care who you are or what you've
done because nobody gets to treat volunteers the way you did above.

Well, a volunteer whose first proposed contribution is a patch to add
modelines to every file in the tree (with the clear subtext that we're
idiots to not have thought of it before) should expect a bit of
push-back. If he'd phrased it as "would this be a good idea?" then
I would have reacted differently.

regards, tom lane

On Fri, 2009-05-01 at 14:44 -0500, Andy Lester wrote:

On May 1, 2009, at 2:37 PM, Joshua D. Drake wrote:

Regardless, I
agree with Tom that the idea of having decorators of any kind in
source
or docs is a bad idea.

Why is it a bad idea? I don't understand the downside of a line or
two at the bottom of a source file.

Maintenance mostly. Of course we could script that but do you really
want decorators for every editor in there that people use? We have a
huge contingent of VI/Emacs not to mention Joe, Nano, Eclipse, TextMate
etc...

Sincerely,

Joshua D. Drake

--
PostgreSQL - XMPP: jdrake@jabber.postgresql.org
Consulting, Development, Support, Training
503-667-4564 - http://www.commandprompt.com/
The PostgreSQL Company, serving since 1997

Because it becomes one more maintenance task we don't need.

There should be nothing to maintain, if it's done right.

The linux kernel is a mess. There are a couple of hundred files
with inconssistent mode lines. Most have none (and there are
thousands).

So it sounds like they could benefit from a tool that ensured that
they would be kept consistent, and so that when it was decided that
changes needed to be made, the single tool (likely a 20-line Perl
program) would take care of it.

So we're hardly alone in not doing it the way you're suggesting.

Sure, and I'm sure there are plenty of projects that do use them to
great effect, most notably Perl 5 and Parrot. Perl 5 specifically has
had the mish-mosh of tabs-vs-spaces reduced by the addition of
modelines.

xoa

--
Andy Lester => andy@petdance.com => www.theworkinggeek.com => AIM:petdance

Well, a volunteer whose first proposed contribution is a patch to add
modelines to every file in the tree (with the clear subtext that we're
idiots to not have thought of it before)

No subtext at all. Perhaps the volunteer figured nobody ever bothered
with it before.

should expect a bit of
push-back. If he'd phrased it as "would this be a good idea?" then
I would have reacted differently.

But since he didn't, it's OK to be insulting?

--
Andy Lester => andy@petdance.com => www.theworkinggeek.com => AIM:petdance

Well, when I read both messages, I read just as much subtext in the
original message as Tom's reply. No more, no less.

To take "personal offence" at what Tom wrote, I think you'ld need to
take "personal offence" at the way the way the initial proposal (or
rather, more the "it just needs to be done") came in.

But hey, maybe I've been around LKML too much just have no
personal-offence-o-meter left...

a.

* Andy Lester <andy@petdance.com> [090501 16:03]:

Well, a volunteer whose first proposed contribution is a patch to add
modelines to every file in the tree (with the clear subtext that we're
idiots to not have thought of it before)

No subtext at all. Perhaps the volunteer figured nobody ever bothered
with it before.

should expect a bit of
push-back. If he'd phrased it as "would this be a good idea?" then
I would have reacted differently.

But since he didn't, it's OK to be insulting?

--
Andy Lester => andy@petdance.com => www.theworkinggeek.com => AIM:petdance

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

--
Aidan Van Dyk Create like a god,
aidan@highrise.ca command like a king,
http://www.highrise.ca/ work like a slave.

Andy Lester <andy@petdance.com> writes:

So we're hardly alone in not doing it the way you're suggesting.

Sure, and I'm sure there are plenty of projects that do use them to
great effect, most notably Perl 5 and Parrot. Perl 5 specifically has
had the mish-mosh of tabs-vs-spaces reduced by the addition of
modelines.

The solution we've used for years is to run pg_indent over the tree
every so often. Unlike modelines, this works regardless of whether
patch authors saw fit to use the modelines ...

regards, tom lane

Hi,

Le 1 mai 09 à 22:02, Andy Lester a écrit :

Because it becomes one more maintenance task we don't need.

There should be nothing to maintain, if it's done right.

Any line in the source tree will have to get maintained, or why would
you spend any time writing it?

So it sounds like they could benefit from a tool that ensured that
they would be kept consistent, and so that when it was decided that
changes needed to be made, the single tool (likely a 20-line Perl
program) would take care of it.

See doc/FAQ_DEV and those specific lines:

First, all the files in the src/tools directory are designed for
developers.

pgindent indents source files

Sure, and I'm sure there are plenty of projects that do use them to
great effect, most notably Perl 5 and Parrot. Perl 5 specifically
has had the mish-mosh of tabs-vs-spaces reduced by the addition of
modelines.

There's also the src/tools/editors/{emacs,vim}.sample files with
exactly what you propose, but more in a central way rather than a
distributed one. The project chose to have this point addressed by
proposing each contributor to setup his $EDITOR and giving samples on
how to achieve this for the most popular ones.

Proposing patches to revisit choices already made in the past usually
need a fair amount of proving why it's a good idea to revisit and how
the new idea is better than the current one. I think the answer you
got was about filling this part of your proposal.

Sorry if the "push-back" has been read as harsh, but I've got the
(very personal) feeling that to become a contributor to PostgreSQL,
you *will* have to be able to read this level of criticism back from
the mail you send.

HTH, Regards,
--
dim

There should be nothing to maintain, if it's done right.

Any line in the source tree will have to get maintained, or why
would you spend any time writing it?

I meant by hand.

See doc/FAQ_DEV and those specific lines:

I see no such file. Perhaps it doesn't get exported into the git
mirror?

Sorry if the "push-back" has been read as harsh, but I've got the
(very personal) feeling that to become a contributor to PostgreSQL,
you *will* have to be able to read this level of criticism back from
the mail you send.

I'm all for criticism of ideas. I wish there had been some in Tom's
original mail.

xoa

--
Andy Lester => andy@petdance.com => www.theworkinggeek.com => AIM:petdance

On Fri, 2009-05-01 at 15:35 -0500, Andy Lester wrote:

There should be nothing to maintain, if it's done right.

Any line in the source tree will have to get maintained, or why
would you spend any time writing it?

I meant by hand.

See doc/FAQ_DEV and those specific lines:

I see no such file. Perhaps it doesn't get exported into the git
mirror?

It is actually:

http://wiki.postgresql.org/wiki/Developer_FAQ

Sincerely,

Joshua D. Drake

--
PostgreSQL - XMPP: jdrake@jabber.postgresql.org
Consulting, Development, Support, Training
503-667-4564 - http://www.commandprompt.com/
The PostgreSQL Company, serving since 1997

On May 1, 2009, at 3:46 PM, Joshua D. Drake wrote:

See doc/FAQ_DEV and those specific lines:

I see no such file. Perhaps it doesn't get exported into the git
mirror?

It is actually:

http://wiki.postgresql.org/wiki/Developer_FAQ

I understand that the FAQ is on the wiki. What I am saying is that my
git repo does not have doc/FAQ_DEV. I didn't see it scroll by in the
CVS repo that I'm rsyncing, either.

--
Andy Lester => andy@petdance.com => www.theworkinggeek.com => AIM:petdance

Le 1 mai 09 à 22:56, Andy Lester a écrit :

http://wiki.postgresql.org/wiki/Developer_FAQ

I understand that the FAQ is on the wiki. What I am saying is that
my git repo does not have doc/FAQ_DEV. I didn't see it scroll by in
the CVS repo that I'm rsyncing, either.

Sorry:
http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/doc/Attic/FAQ_DEV

It's in the attic after having been removed, replaced by the wiki
reference page. The copy where I looked for reference material wasn't
HEAD. Sorry about that.

I see that src/DEVELOPERS is not up to date, it's not referring to the
wiki page:
http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/DEVELOPERS?rev=1.5

Regards,
--
dim

On Fri, 2009-05-01 at 15:56 -0500, Andy Lester wrote:

On May 1, 2009, at 3:46 PM, Joshua D. Drake wrote:

See doc/FAQ_DEV and those specific lines:

I see no such file. Perhaps it doesn't get exported into the git
mirror?

It is actually:

http://wiki.postgresql.org/wiki/Developer_FAQ

I understand that the FAQ is on the wiki. What I am saying is that my
git repo does not have doc/FAQ_DEV. I didn't see it scroll by in the
CVS repo that I'm rsyncing, either.

Right. That is because it isn't there anymore. It was moved to the wiki.

Joshua D. Drake

--
PostgreSQL - XMPP: jdrake@jabber.postgresql.org
Consulting, Development, Support, Training
503-667-4564 - http://www.commandprompt.com/
The PostgreSQL Company, serving since 1997

--
Greg

On 1 May 2009, at 21:09, David Fetter <david@fetter.org> wrote:

On Fri, May 01, 2009 at 11:23:24AM -0400, Tom Lane wrote:

We had a similar thing for awhile with the .sgml files, and got rid
of
that because it sucked ...

I'd appreciate your making an argument, if you're going to, on the
merits of the proposal at hand, rather than stooping to personal
insult.

Eh? The reply was terse but it's not a personal insult to say we've
tried the suggestion before and decided it was a bad idea.

Andy Lester wrote:

I've got my git clone set up, a copy of GCC 4.4 (and other compilers) at
the ready, and am glad to help out on low-level scut work. Anybody need
anything done? splint? valgrind? Let me know.

If you have some time to kill, perhaps you could check the Coverity bug
list and see if anything hasn't been handled that should be.

http://scan2.coverity.com:7455/
http://scan.coverity.com/devfaq.html

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

On Fri, May 1, 2009 at 4:35 PM, Andy Lester <andy@petdance.com> wrote:

There should be nothing to maintain, if it's done right.

Any line in the source tree will have to get maintained, or why would you
spend any time writing it?

I meant by hand.

See doc/FAQ_DEV and those specific lines:

I see no such file.  Perhaps it doesn't get exported into the git mirror?

Sorry if the "push-back" has been read as harsh, but I've got the (very
personal) feeling that to become a contributor to PostgreSQL, you *will*
have to be able to read this level of criticism back from the mail you send.

I'm all for criticism of ideas.  I wish there had been some in Tom's
original mail.

OK, so, when I initially started catching up on this thread, I was
kind of feeling annoyed at Tom, and I still wish he'd say something
along the lines of "I did not mean to give offense and I'm sorry if my
words came across in a way that I did not intend" rather than just
explaining why he reacted the way he did. That having been said, as
far as I can tell, your feeling that Tom said something rude is based
largely on the fact that he used the word "sucked", and perhaps the
phrase "rejected out of hand". Admittedly, Tom could have described
why he thought it sucked rather than just saying that it did, and he
could have said that he would vote against accepting it and believed
that others would not like it either rather than phrasing it in the
way that he did.

Then again, you didn't offer any justification for your desire to have
them in there either. You didn't ask whether they'd been previously
considered or whether the community would find them desirable. You
didn't make an argument for why they'd be better than the system
currently in use or even, at least as far as can be determined from
reading the email that set off this flame war, take the time to
understand that system before proposing your own.

One thing I have discovered about pgsql-hackers is that it is very
easy to be accused of not having done your homework even if you
actually have. I have seen more than one well-thought-out proposal
shot down by a committer who (as it seemed to me) had thought it
through less carefully than the person proposing it. On the other
hand, there are five or ten half-baked ideas for every good one, so
the committers have something of a difficult job sifting the wheat
from the chaff. If this initial bad experience doesn't turn you off
to this community (and I hope it won't), then I think the moral of the
story is to make sure that you've done your homework before you put
forward a specific proposal. Search the archives and be ready to
answer objections that were raised to your idea previously, or to
similar ideas, if any. Read the documentation, which is excellent and
contains not only descriptions of the functionality of PostgreSQL but
a certain amount of discussion of the internals, implementation, etc.
Since you're a git user, use "git log <pathspec>" and "git log
-S<word>" to sift through the history, and "git grep <regexp>" to
search the current tree. Browse the wiki (though it's navigability is
less than excellent) and Google a bunch of related terms. Then write
up your idea and send it out in the form of a proposal, and see if you
get any support. Lack of a response is not necessarily fatal (you can
bring it up again in a month or two, perhaps in response to a related
suggestion from someone else; or add it the CommitFest wiki if it's a
patch) but if you get a couple of -1s you probably need to rethink
things. I have yet to see anything that I thought was a really good
idea have more than one person speak against it, which I think speaks
to the fact that this community includes a lot of very, very smart and
sharp people. I'm sorry that it's come across as inhospitable, but I
hope you decide to tough it out.

...Robert

-----Original Message-----
From: pgsql-hackers-owner@postgresql.org [mailto:pgsql-hackers-
owner@postgresql.org] On Behalf Of Robert Haas
Sent: Friday, May 01, 2009 6:00 PM
To: Andy Lester
Cc: Dimitri Fontaine; PostgreSQL-development
Subject: Re: [HACKERS] Throw some low-level C scutwork at me

On Fri, May 1, 2009 at 4:35 PM, Andy Lester <andy@petdance.com> wrote:

There should be nothing to maintain, if it's done right.

Any line in the source tree will have to get maintained, or why

would you

spend any time writing it?

I meant by hand.

See doc/FAQ_DEV and those specific lines:

I see no such file.  Perhaps it doesn't get exported into the git

mirror?

Sorry if the "push-back" has been read as harsh, but I've got the

(very

personal) feeling that to become a contributor to PostgreSQL, you

*will*

have to be able to read this level of criticism back from the mail

you send.

I'm all for criticism of ideas.  I wish there had been some in Tom's
original mail.

OK, so, when I initially started catching up on this thread, I was
kind of feeling annoyed at Tom, and I still wish he'd say something
along the lines of "I did not mean to give offense and I'm sorry if my
words came across in a way that I did not intend" rather than just
explaining why he reacted the way he did.

I think it's just Tom's way.

Higgins (from Pygmalion):
The great secret, Eliza, is not having bad manners or good manners or any other particular sort of manners, but having the same manner for all human souls: in short, behaving as if you were in Heaven, where there are no third-class carriages, and one soul is as good as another.

For comparison, here is a recent message from Tom addressed to me, along with my response:
=================================================================

-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: Tuesday, April 28, 2009 3:21 PM
To: Dann Corbit
Cc: Andrew Dunstan; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Building Postgresql under Windows question

"Dann Corbit" <DCorbit@connx.com> writes:

From: Andrew Dunstan [mailto:andrew@dunslane.net]

Why won't
PQstatus(conn) == CONNECTION_OK
be true and thus the code will succeed without requiring a password?

It returns the value CONNECTION_STARTED

It certainly shouldn't. You're effectively asserting that PQconnectdb
is broken for everyone on every platform, which is demonstrably not the
case. Are you fooling with modified libpq code by any chance?

No.
The service works correctly when I use password authentication.
The service does not work correctly when I use trust.

What happens when you use trust in pg_hba.conf?
=================================================================

Now, I do not think that Tom is a bad person at all. Quite the contrary, he's clearly very smart and also goes to great lengths in attempts to be helpful (sometimes chewing someone out is being helpful as well). He sometimes comes off as brusque -- but to some degree that comes from reading between the lines and being over sensitive.

I think the lesson to be learned here is that when making any sort of message sent to the internet, the most sensible policy is to grow a skin at least five inches thick.

I am certainly glad that Tom is on the PostgreSQL team. I expect that the product will come out ahead from it in the long run. And as for being offended, I am reminded of a Bible proverb:
(Ecclesiastes 7:9) Do not hurry yourself in your spirit to become offended, for the taking of offense is what rests in the bosom of the stupid ones.

Hi,

OK, so, when I initially started catching up on this thread, I was
kind of feeling annoyed at Tom, and I still wish he'd say something
along the lines of "I did not mean to give offense and I'm sorry if my
words came across in a way that I did not intend" rather than just
explaining why he reacted the way he did.

I think it's just Tom's way.

Sure is :). And those who have been on this list long enough do know and
appreciate the value of his technical comments. And you just got to see the
code that he checks-in - it always is in the best possible shape!

Regards,
Nikhils

Higgins (from Pygmalion):
The great secret, Eliza, is not having bad manners or good manners or any
other particular sort of manners, but having the same manner for all human
souls: in short, behaving as if you were in Heaven, where there are no
third-class carriages, and one soul is as good as another.

For comparison, here is a recent message from Tom addressed to me, along
with my response:
=================================================================

-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: Tuesday, April 28, 2009 3:21 PM
To: Dann Corbit
Cc: Andrew Dunstan; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Building Postgresql under Windows question

"Dann Corbit" <DCorbit@connx.com> writes:

From: Andrew Dunstan [mailto:andrew@dunslane.net]

Why won't
PQstatus(conn) == CONNECTION_OK
be true and thus the code will succeed without requiring a password?

It returns the value CONNECTION_STARTED

It certainly shouldn't. You're effectively asserting that PQconnectdb
is broken for everyone on every platform, which is demonstrably not the
case. Are you fooling with modified libpq code by any chance?

No.
The service works correctly when I use password authentication.
The service does not work correctly when I use trust.

What happens when you use trust in pg_hba.conf?
=================================================================

Now, I do not think that Tom is a bad person at all. Quite the contrary,
he's clearly very smart and also goes to great lengths in attempts to be
helpful (sometimes chewing someone out is being helpful as well). He
sometimes comes off as brusque -- but to some degree that comes from reading
between the lines and being over sensitive.

I think the lesson to be learned here is that when making any sort of
message sent to the internet, the most sensible policy is to grow a skin at
least five inches thick.

I am certainly glad that Tom is on the PostgreSQL team. I expect that the
product will come out ahead from it in the long run. And as for being
offended, I am reminded of a Bible proverb:
(Ecclesiastes 7:9) Do not hurry yourself in your spirit to become offended,
for the taking of offense is what rests in the bosom of the stupid ones.

That having been said, as
far as I can tell, your feeling that Tom said something rude is based
largely on the fact that he used the word "sucked", and perhaps the
phrase "rejected out of hand". Admittedly, Tom could have described
why he thought it sucked rather than just saying that it did, and he
could have said that he would vote against accepting it and believed
that others would not like it either rather than phrasing it in the
way that he did.

Then again, you didn't offer any justification for your desire to have
them in there either. You didn't ask whether they'd been previously
considered or whether the community would find them desirable. You
didn't make an argument for why they'd be better than the system
currently in use or even, at least as far as can be determined from
reading the email that set off this flame war, take the time to
understand that system before proposing your own.

One thing I have discovered about pgsql-hackers is that it is very
easy to be accused of not having done your homework even if you
actually have. I have seen more than one well-thought-out proposal
shot down by a committer who (as it seemed to me) had thought it
through less carefully than the person proposing it. On the other
hand, there are five or ten half-baked ideas for every good one, so
the committers have something of a difficult job sifting the wheat
from the chaff. If this initial bad experience doesn't turn you off
to this community (and I hope it won't), then I think the moral of the
story is to make sure that you've done your homework before you put
forward a specific proposal. Search the archives and be ready to
answer objections that were raised to your idea previously, or to
similar ideas, if any. Read the documentation, which is excellent and
contains not only descriptions of the functionality of PostgreSQL but
a certain amount of discussion of the internals, implementation, etc.
Since you're a git user, use "git log <pathspec>" and "git log
-S<word>" to sift through the history, and "git grep <regexp>" to
search the current tree. Browse the wiki (though it's navigability is
less than excellent) and Google a bunch of related terms. Then write
up your idea and send it out in the form of a proposal, and see if you
get any support. Lack of a response is not necessarily fatal (you can
bring it up again in a month or two, perhaps in response to a related
suggestion from someone else; or add it the CommitFest wiki if it's a
patch) but if you get a couple of -1s you probably need to rethink
things. I have yet to see anything that I thought was a really good
idea have more than one person speak against it, which I think speaks
to the fact that this community includes a lot of very, very smart and
sharp people. I'm sorry that it's come across as inhospitable, but I
hope you decide to tough it out.

...Robert

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

--
http://www.enterprisedb.com