Thread: Throw some low-level C scutwork at me

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.

xoxo,
Andy

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

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

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

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

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

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

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

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

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

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.

>> 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
thesame 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
greatlengths in attempts to be helpful (sometimes chewing someone out is being helpful as well).  He sometimes comes
offas 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
policyis 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
longrun.  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
thebosom 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