On Mon, Feb 25, 2019 at 1:17 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > I'm not following your point here. If we change key data structures > (i.e. parsetrees, plan trees, execution trees) to use some other list-ish > API, that *in itself* breaks everything that accesses those data > structures. The approach I propose here isn't zero-breakage, but it > requires far fewer places to be touched than a complete API replacement > would do.
Sure, but if you have third-party code that touches those things, it'll fail to compile. With your proposed approach, there seems to be a risk that it will compile but not work. > Yup. So are you saying that we'll never redesign parsetrees again? > We break things regularly, as long as the cost/benefit justifies it. I'm mostly objecting to the degree that the breakage is *silent*. > I completely disagree. Your proposal is probably an order of magnitude > more painful than the approach I suggest here, while not really offering > any additional performance benefit (or if you think there would be some, > you haven't explained how). Strictly on cost/benefit grounds, it isn't > ever going to happen that way. Why would it be ten times more painful, exactly? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
