On Wed, Dec 10, 2014 at 11:22 AM, Stephen Frost <sfr...@snowman.net> wrote: > I'm not quite sure that I see how that's relevant. Bugs will happen, > unfortunately, no matter how much review is done of a given patch. That > isn't to say that we shouldn't do any review, but it's a trade-off. > This change, at least, strikes me as less likely to have subtle bugs > in it as compared to the dropped column case.
Yeah, that's possible. They seem similar to me because they both introduce new ways for the tuple as it is stored on disk to be different from what must be shown to the user. But I don't really know how well that translates to what needs to be changed on a code level. If we're basically going back over all the same places that needed special handling for attisdropped, then the likelihood of bugs may be quite a bit lower than it was for that patch, because now we know (mostly!) which places require attisdropped handling and we can audit them all to make sure they handle this, too. But if it's a completely different set of places that need to be touched, then I think there's a lively possibility for bugs of omission. Ultimately, I think this is mostly going to be a question of what Alvaro feels comfortable with; he's presumably going to have a better sense of where and to what extent there might be bugs lurking than any of the rest of us. But the point is worth considering, because I think we would probably all agree that having a release that is stable and usable right out of the gate is more important than having any single feature get into that release. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers