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 по дате отправления:

Предыдущее
От: Dan Ports
Дата:
Сообщение: Re: SSI predicate locking on heap -- tuple or row?
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Pull up aggregate subquery