Re: Identifying no-op length coercions
От | Noah Misch |
---|---|
Тема | Re: Identifying no-op length coercions |
Дата | |
Msg-id | 20110523184643.GB14758@tornado.gateway.2wire.net обсуждение исходный текст |
Ответ на | Re: Identifying no-op length coercions (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Identifying no-op length coercions
Re: Identifying no-op length coercions |
Список | pgsql-hackers |
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? Thanks, nm
В списке pgsql-hackers по дате отправления: