On Wed, Jan 26, 2011 at 6:06 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > I'm not sure how important that concern is though, because it's hard to > see how any such change wouldn't break existing cast implementation > functions anyway. If the API for length-coercing cast functions > changes, breaking their helper functions too hardly seems like an issue. > Or are you saying you want to punt this whole proposal till after that > happens? I had muttered something of the sort way upthread, but I > didn't think anyone else thought that way.
I've been thinking about this patch a little bit more and I'm coming around to the viewpoint that we should mark this (and the successor patches in the same series) Returned with Feedback, and revisit the issue for 9.2. I'm not necessarily signing on to the viewpoint that we should wait to do any of this work until after we refactor typemods, but it does strike me that the fact that Tom and I have completely different ideas of how this will interact with future changes in this area probably means we need to take some more time to talk about what those future enhancements might look like, rather than rushing something now and maybe regretting it later. We may not need to actually do all that work before we do this, but it sounds like at a minimum we need some agreement on what the design should look like. I think there is still hope for ALTER TYPE 2 (really ALTER TABLE 2 or SET DATA TYPE 2; it's misnamed) to be committed this cycle and I'll continue reviewing that one to see whether we can get at least that much done for 9.1. But I think the rest of this just needs more time than we have to give it right now. There are more than 60 patches left open in the CommitFest at this point, and we have less than three weeks left. If we don't focus our efforts on the things where we have clear agreement and good, finished code, we're going to end up either dragging this CommitFest out for months or else getting very little done for the next few weeks and then indiscriminately punting whatever is left over at the end. I don't want to do either of those things, so that means it's time to start making some tough choices, and unfortunately I think this is one that's going to have to get cut, for lack of agreement on the basic design. -- 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