On Mon, May 23, 2011 at 2:46 PM, Noah Misch <n...@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 <t...@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? Just to throw out another few possibilities, how about INLINE FUNCTION or ANALYZE FUNCTION? -- 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
