Обсуждение: pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY
pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY
От
alvherre@postgresql.org (Alvaro Herrera)
Дата:
Log Message: ----------- Refactor NUM_cache_remove calls in error report path to a PG_TRY block. The code in the new block was not reindented; it will be fixed by pgindent eventually. Modified Files: -------------- pgsql/src/backend/utils/adt: formatting.c (r1.160 -> r1.161) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/adt/formatting.c?r1=1.160&r2=1.161)
On Mon, Aug 10, 2009 at 4:16 PM, Alvaro Herrera<alvherre@postgresql.org> wrote: > Log Message: > ----------- > Refactor NUM_cache_remove calls in error report path to a PG_TRY block. > > The code in the new block was not reindented; it will be fixed by pgindent > eventually. ...breaking every patch that someone has in progress against that code? ...Robert
Robert Haas escribió: > On Mon, Aug 10, 2009 at 4:16 PM, Alvaro Herrera<alvherre@postgresql.org> wrote: > > Log Message: > > ----------- > > Refactor NUM_cache_remove calls in error report path to a PG_TRY block. > > > > The code in the new block was not reindented; it will be fixed by pgindent > > eventually. > > ...breaking every patch that someone has in progress against that code? I guess I neglected to add "a year from now or so". I'm not in a hurry to run pgindent. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
On Mon, Aug 10, 2009 at 4:22 PM, Alvaro Herrera<alvherre@commandprompt.com> wrote: > Robert Haas escribió: >> On Mon, Aug 10, 2009 at 4:16 PM, Alvaro Herrera<alvherre@postgresql.org> wrote: >> > Log Message: >> > ----------- >> > Refactor NUM_cache_remove calls in error report path to a PG_TRY block. >> > >> > The code in the new block was not reindented; it will be fixed by pgindent >> > eventually. >> >> ...breaking every patch that someone has in progress against that code? > > I guess I neglected to add "a year from now or so". I'm not in a hurry > to run pgindent. Me neither, but every place that we know pgindent will touch is like a little land-mine waiting to go off under somebody's patch. It seems like we ought to try to keep the tree as pgindent-clean as possible when we make changes, so that there are as few of those land-mines out there as possible. ...Robert
Alvaro Herrera <alvherre@commandprompt.com> writes: > Robert Haas escribi�: >>> The code in the new block was not reindented; it will be fixed by pgindent >>> eventually. >> >> ...breaking every patch that someone has in progress against that code? > I guess I neglected to add "a year from now or so". I'm not in a hurry > to run pgindent. Yeah --- if there are any active patches against that code (a fact not in evidence) then reindenting now would break them now. Leaving it till the next pgindent run seems fine to me. regards, tom lane
On Mon, Aug 10, 2009 at 4:31 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote: > Alvaro Herrera <alvherre@commandprompt.com> writes: >> Robert Haas escribió: >>>> The code in the new block was not reindented; it will be fixed by pgindent >>>> eventually. >>> >>> ...breaking every patch that someone has in progress against that code? > >> I guess I neglected to add "a year from now or so". I'm not in a hurry >> to run pgindent. > > Yeah --- if there are any active patches against that code (a fact not > in evidence) then reindenting now would break them now. Leaving it till > the next pgindent run seems fine to me. But if there are patches against that code, then they've been broken now and they will break again when the pgindent run is done. If the indentation is fixed at commit-time (or before someone goes to the trouble of fixing them), then they get broken only once. I guess it's not the end of the world, but it sure seems like the less work pgindent does when it is run, the better. ...Robert
Robert Haas <robertmhaas@gmail.com> writes: > On Mon, Aug 10, 2009 at 4:31 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote: >> Yeah --- if there are any active patches against that code (a fact not >> in evidence) then reindenting now would break them now. �Leaving it till >> the next pgindent run seems fine to me. > But if there are patches against that code, then they've been broken > now Uh, no --- the point here is that something like two hundred lines of code were *not* changed by reindenting. Diffs in that area would likely still apply. > and they will break again when the pgindent run is done. Only if they aren't applied by then. One reason that we normally only run pgindent at the end of the devel cycle is that that's when (presumably) the smallest amount of patches remain outstanding. regards, tom lane
On Mon, Aug 10, 2009 at 6:52 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> On Mon, Aug 10, 2009 at 4:31 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote: >>> Yeah --- if there are any active patches against that code (a fact not >>> in evidence) then reindenting now would break them now. Leaving it till >>> the next pgindent run seems fine to me. > >> But if there are patches against that code, then they've been broken >> now > > Uh, no --- the point here is that something like two hundred lines of > code were *not* changed by reindenting. Diffs in that area would likely > still apply. > >> and they will break again when the pgindent run is done. > > Only if they aren't applied by then. One reason that we normally only > run pgindent at the end of the devel cycle is that that's when > (presumably) the smallest amount of patches remain outstanding. OK, I get it. Thanks for bearing with me. The theory that the smallest amount of patches remain outstanding at that point is probably only true if the pgindent run is done relatively soon after the last CommitFest. In the 8.4 cycle, the pgindent run was done something like 7 months after the start of the last CommitFest, by which time a fair number of patches had accumulated. ...Robert