On Mon, May 23, 2011 at 02:53:01PM -0400, Robert Haas wrote:
> On Mon, May 23, 2011 at 2:46 PM, Noah Misch <noah@leadboat.com> wrote:
> > On Mon, May 23, 2011 at 02:11:39PM -0400, Robert Haas wrote:
> >> On Mon, May 23, 2011 at 1:53 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >> > Maybe. ?But casts would be the least of our concerns if we were trying
> >> > to change the column type. ?Changing typmod doesn't affect the set of
> >> > operations that could be applied to a column, whereas changing type
> >> > surely does.
> >>
> >> OK, this is the crucial point I was missing. ?Sorry for being a bit
> >> fuzzy-headed about this.
> >>
> >> My mental model of our type system, or of what a type system ought to
> >> do, just doesn't match the type system we've got.
> >>
> >> So let's do it the way you proposed.
> >
> > Good deal. ?Given that conclusion, the other policy decision I anticipate
> > affecting this particular patch is the choice of syntax. ?Presumably, it will be
> > a new common_func_opt_item. ?When I last looked at the keywords list and tried
> > to come up with something, these were the best I could do:
> >
> > ?CREATE FUNCTION ... PARSER MAPPING helperfunc(args)
> > ?CREATE FUNCTION ... PLANS CONVERSION helperfunc(args)
> >
> > Both feel forced, to put it generously. ?Any better ideas? ?Worth adding a
> > keyword to get something decent?
>
> Do you have something specific in mind?
I had not. Having thought about it some, maybe "PLAN TRANSFORM FUNCTION". Do
we have a name for the pass over the tree rooted at eval_const_expressions()?
> Just to throw out another few possibilities, how about INLINE FUNCTION
> or ANALYZE FUNCTION?
INLINE FUNCTION evokes, for me, having a different version of a function that
gets substituted when it's inlined. ANALYZE FUNCTION seems reasonable, though.
I don't think any name we'd pick will make a significant number of readers
understand it without reading the full documentation.
nm
