Re: Avoid a possible out-of-bounds access (src/backend/optimizer/util/relnode.c)

On Fri, 29 Sept 2023 at 01:00, Ranier Vilela <ranier.vf@gmail.com> wrote:
> Perhaps, and using your own words, the leaders on this project seem
> to be against reviewers armed with blunderbuss, too.

I don't have any ideas on what you're talking about here, but if this
is a valid concern that you think is unfair then maybe the code of
conduct team is a more relevant set of people to raise it with.

My mention of the scattergun approach to writing patches was aimed at
helping you have more success here.  I'd recommend you resist the urge
to change unrelated code in your patches. Your experience here might
improve if you're able to aim your patches at resolving specific
issues.  I know you'd love to see commit messages that include "In
passing, adjust a random assortment of changes contributed by Ranier
Vilela".  That's just not going to happen. You might think the
committer's job is just to commit patches contributed by contributors,
but what you might not realise is that we're also trying to maintain a
codebase that's over 3 decades old and will probably outlive most of
its current contributors.  Making things easy both for ourselves in
several years time and for our future counterparts is something that
we do need to consider when discussing and making changes.  The mail
archives and commit messages are an audit trail for our future selves
and future counterparts.  That's one of the main reasons why we tend
to not like you trying to sneak in assortments of random changes along
with your change. If you can understand this and adapt to this way of
thinking then you're more likely to find yourself feeling like you're
working with committers and other contributors rather than against
them.

I say this hoping you take it constructively, but I find that you're
often very defensive about your patches and often appear to take
change requests in a very negative way.  On this thread you've
demonstrated to me that by me requesting you to remove an unrelated
change in the patch that I must not care about code quality in
PostgreSQL.  I personally find these sorts of responses quite draining
and it makes me not want to touch your work. I would imagine I'm not
the only person that feels this. So there's a real danger here that if
you continue to have too many negative responses in emails, you'll
find yourself ignored and you're likely to find that frustrating and
that will lead to you having a worse experience here.   This does not
mean you have to become passive to all requests for changes to your
patches, but if you're going to argue or resist, then it pays to
politely explain your reasoning so that the topic can be discussed
constructively.

> I confess that some "in pass", "while there", and some desire to enrich the patch, clouded my judgment.

I'm glad to see you're keen to make improvements to PostgreSQL,
however, I'd like to suggest that you channel that energy and aim to
produce patches targeted in those areas that attempt to resolve a
series or perhaps all problems of that particular category in
isolation.  If it's a large patch then it's likely best to get
consensus first as having lots of work rejected is always more
painful.

> So it seems that we have some consensus, I propose version 2 of the patch,
> which I hope we will have to correct, perhaps, the words of the comments.

I've pushed this patch after making an adjustment to the comment to
shorten it to a single line.

Thank you for working on this.

David