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

On Fri, Jan 28, 2011 at 4:49 PM, Noah Misch <noah(at)leadboat(dot)com> wrote:
>> 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.

Once we add syntax to support this feature, we have to support that
syntax for an extremely long time. We can't just remove it in the
next release and replace it with something else - pg_dump has to still
work, for example, and we have to able to reload whatever it produces.
Adding a user-visible API that we may want to turn around and change
*next release* is just a bad idea. If we were talking about
implementing this through some sort of hard-coded internal list of
types, it wouldn't be quite so much of an issue, but that's not where
we're at. Moreover, I fear that injecting this into
eval_const_expressions() is adding a frammish that has no practical
utility apart from this case, but we still have to pay the overhead;
even Tom expressed some initial doubt about whether that made sense,
and I'm certainly not sold on it either. I don't see any particular
reason why we can't resolve all of these issues, but it's going to
take more time than we have right now.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company