Re: [Proposal] Level4 Warnings show many shadow vars

From: John W Higgins <wishdev(at)gmail(dot)com>
To: "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: [Proposal] Level4 Warnings show many shadow vars
Date: 2019-12-11 18:33:20
Message-ID: CAPhAwGwpbTV-k8tM2RKwzbjBANXihT+-utOAJFNBpErSy9b8nQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Dec 11, 2019 at 9:46 AM Ranier Vilela <ranier_gyn(at)hotmail(dot)com>
wrote:

> I am the author of the patch.
> I'm repeating myself, but come on, I don't have confidence in proposing
> logic-altering changes for now.
>
>
Then you need to stop and patch the holes and not just throw paint on the
wall to cover things up.

Specific example

src/bin/pgdump/common.c

That file discusses the purpose of numTables

* These variables are static to avoid the notational cruft of having to
pass
* them into findTableByOid() and friends.

Then the file goes and doesn't follow that logic by passing numTables
around to a bunch of functions within itself.

The fix here, very much appears to be to remove the spurious numTables in
the functions.

However, if you cannot, or will not, take the opportunity to correct it
properly - as has been asked earlier for this specific file - then please
just leave it alone.

There have been plenty of emails on these threads where folks have looked
at your work and discussed whether or not specific things should be changed
based on your analysis - that's an amazing thing to see occur - but that's
getting overwhelmed by your inability to take a step back and stop just
throwing stuff on the wall.

I've mentioned inconsistencies in your patches - that is a product of just
trying to throw something on the wall to cover over the issue - hiding a
hole in the wall with something doesn't remove the hole in the wall.

You would be so much better off taking on one specific instance at a time
and working with folks to learn how the code functions. If you don't think
you can handle the bigger issues - then stick with things like numTables
and the clear issues within your grasp first.

I truly do wish you all the best - but you do not seem to be approaching
these issues with the correct mindset at the moment. Volume is not the
winner over quality here.

John W Higgins

>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2019-12-11 18:35:26 Re: global / super barriers (for checksums)
Previous Message Robert Haas 2019-12-11 18:16:28 Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions