Re: ALTER TYPE 3: add facility to identify further no-work cases

On Fri, Jan 28, 2011 at 01:52:32PM -0500, Robert Haas wrote:
> On Wed, Jan 26, 2011 at 6:06 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.

This is just.

> 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've deferred comment due to my obvious bias, but I can't see any sense in
blocking a change like this one on account of the exceptionally-preliminary
discussions about enriching typmod. Suppose, like my original design, we make
no provision to insulate against future typmod-related changes. The number of
interfaces that deal in typmod are so great that the marginal effort to update
the new ones will be irrelevant. I still like Tom's idea of an Expr<->Expr
interface. I like it because it opens more opportunities now, not because it
will eliminate some modicum of effort from an enriched-typmod implementation.

nm