Re: [HACKERS] nodes/*funcs.c inconsistencies

2015-11-06 Thread Peter Geoghegan
On Mon, Aug 3, 2015 at 10:00 AM, Alvaro Herrera wrote: >> Couldn't we adopt >> AssertVariableIsOfType()/AssertVariableIsOfTypeMacro() to macros like >> READ_UINT_FIELD()? >> >> I'm surprised that this stuff was only ever used for logical decoding >> infrastructure so

Re: [HACKERS] nodes/*funcs.c inconsistencies

2015-08-06 Thread Stephen Frost
Noah, * Noah Misch (n...@leadboat.com) wrote: Rather than commit on an emergency basis in the few hours between these +1's and the wrap, I kept to my original schedule. FYI, if it hadn't required emergency procedures (cancelling the day's plans so I could get to a notebook computer), I would

Re: [HACKERS] nodes/*funcs.c inconsistencies

2015-08-05 Thread Noah Misch
On Mon, Aug 03, 2015 at 09:57:52AM -0700, Joe Conway wrote: On 08/03/2015 09:55 AM, Stephen Frost wrote: * Noah Misch (n...@leadboat.com) wrote: On Sun, Aug 02, 2015 at 11:31:16PM -0400, Tom Lane wrote: That being the case, it would probably be a good idea to get them done before alpha2,

Re: [HACKERS] nodes/*funcs.c inconsistencies

2015-08-03 Thread Alvaro Herrera
Peter Geoghegan wrote: On Sun, Aug 2, 2015 at 3:07 PM, Peter Geoghegan p...@heroku.com wrote: I'm surprised that this stuff was only ever used for logical decoding infrastructure so far. On second thought, having tried it, one reason is that that breaks things that are considered

Re: [HACKERS] nodes/*funcs.c inconsistencies

2015-08-03 Thread Alvaro Herrera
Peter Geoghegan wrote: Couldn't we adopt AssertVariableIsOfType()/AssertVariableIsOfTypeMacro() to macros like READ_UINT_FIELD()? I'm surprised that this stuff was only ever used for logical decoding infrastructure so far. The reason it's only used there is that Andres is the one who

Re: [HACKERS] nodes/*funcs.c inconsistencies

2015-08-03 Thread Stephen Frost
* Noah Misch (n...@leadboat.com) wrote: On Sun, Aug 02, 2015 at 11:31:16PM -0400, Tom Lane wrote: That being the case, it would probably be a good idea to get them done before alpha2, as there may not be a good opportunity afterwards. Freedom to bump catversion after alpha2 will be

Re: [HACKERS] nodes/*funcs.c inconsistencies

2015-08-02 Thread Noah Misch
On Sun, Aug 02, 2015 at 11:31:16PM -0400, Tom Lane wrote: Stephen Frost sfr...@snowman.net writes: Noah, A fresh audit found the attached problems new in 9.5[1]. Most are cosmetic INT/UINT or field order corrections. The non-cosmetic changes involve CustomPath, CustomScan, and

Re: [HACKERS] nodes/*funcs.c inconsistencies

2015-08-02 Thread Tom Lane
Stephen Frost sfr...@snowman.net writes: Noah, A fresh audit found the attached problems new in 9.5[1]. Most are cosmetic INT/UINT or field order corrections. The non-cosmetic changes involve CustomPath, CustomScan, and CreatePolicyStmt. Feature committers, if the existing treatments

Re: [HACKERS] nodes/*funcs.c inconsistencies

2015-08-02 Thread Tom Lane
Noah Misch n...@leadboat.com writes: On Mon, Apr 16, 2012 at 06:25:15AM -0400, Noah Misch wrote: I observed these inconsistencies in node support functions: A fresh audit found the attached problems new in 9.5[1]. Many thanks for doing that; I'd had the same checking on my personal to-do

Re: [HACKERS] nodes/*funcs.c inconsistencies

2015-08-02 Thread Noah Misch
On Mon, Apr 16, 2012 at 06:25:15AM -0400, Noah Misch wrote: I observed these inconsistencies in node support functions: A fresh audit found the attached problems new in 9.5[1]. Most are cosmetic INT/UINT or field order corrections. The non-cosmetic changes involve CustomPath, CustomScan, and

Re: [HACKERS] nodes/*funcs.c inconsistencies

2015-08-02 Thread Peter Geoghegan
On Sun, Aug 2, 2015 at 1:28 PM, Noah Misch n...@leadboat.com wrote: A fresh audit found the attached problems new in 9.5[1]. Most are cosmetic INT/UINT or field order corrections. I was responsible for a couple of the cosmetic ones. Sorry about that. It occurs to me that we could do a little

Re: [HACKERS] nodes/*funcs.c inconsistencies

2015-08-02 Thread Peter Geoghegan
On Sun, Aug 2, 2015 at 3:07 PM, Peter Geoghegan p...@heroku.com wrote: I'm surprised that this stuff was only ever used for logical decoding infrastructure so far. On second thought, having tried it, one reason is that that breaks things that are considered legitimate for historical reasons.

Re: [HACKERS] nodes/*funcs.c inconsistencies

2015-08-02 Thread Stephen Frost
Noah, * Noah Misch (n...@leadboat.com) wrote: On Mon, Apr 16, 2012 at 06:25:15AM -0400, Noah Misch wrote: I observed these inconsistencies in node support functions: A fresh audit found the attached problems new in 9.5[1]. Most are cosmetic INT/UINT or field order corrections. The

Re: [HACKERS] nodes/*funcs.c inconsistencies

2015-08-02 Thread Kouhei Kaigai
On Mon, Apr 16, 2012 at 06:25:15AM -0400, Noah Misch wrote: I observed these inconsistencies in node support functions: A fresh audit found the attached problems new in 9.5[1]. Most are cosmetic INT/UINT or field order corrections. The non-cosmetic changes involve CustomPath, CustomScan,

Re: [HACKERS] nodes/*funcs.c inconsistencies

2015-08-02 Thread Noah Misch
On Mon, Aug 03, 2015 at 01:32:10AM +, Kouhei Kaigai wrote: On Mon, Apr 16, 2012 at 06:25:15AM -0400, Noah Misch wrote: I observed these inconsistencies in node support functions: A fresh audit found the attached problems new in 9.5[1]. Most are cosmetic INT/UINT or field order

Re: [HACKERS] nodes/*funcs.c inconsistencies

2012-04-18 Thread Robert Haas
On Mon, Apr 16, 2012 at 6:25 AM, Noah Misch n...@leadboat.com wrote: I'd suggest backpatching the ReassignOwnedStmt() bits; the wrong code could produce crashes.  The rest are for master only. Done, in the manner you suggest. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The

Re: [HACKERS] nodes/*funcs.c inconsistencies

2012-04-18 Thread Alvaro Herrera
Excerpts from Robert Haas's message of mié abr 18 11:47:37 -0300 2012: On Mon, Apr 16, 2012 at 6:25 AM, Noah Misch n...@leadboat.com wrote: I'd suggest backpatching the ReassignOwnedStmt() bits; the wrong code could produce crashes.  The rest are for master only. Done, in the manner you