Re: Identifying no-op length coercions

From: Noah Misch <noah(at)leadboat(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Identifying no-op length coercions
Date: 2011-05-23 18:46:43
Message-ID: 20110523184643.GB14758@tornado.gateway.2wire.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(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?

Thanks,
nm

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2011-05-23 18:49:29 Re: Pull up aggregate subquery
Previous Message Dan Ports 2011-05-23 18:32:33 Re: SSI predicate locking on heap -- tuple or row?