From: | Noah Misch <noah(at)leadboat(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Identifying no-op length coercions |
Date: | 2011-05-23 21:14:53 |
Message-ID: | 20110523211453.GC14758@tornado.gateway.2wire.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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(at)leadboat(dot)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(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Noah Misch | 2011-05-23 21:15:13 | Re: Identifying no-op length coercions |
Previous Message | Kevin Grittner | 2011-05-23 21:06:23 | Re: SSI predicate locking on heap -- tuple or row? |