From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Noah Misch <noah(at)leadboat(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 18:53:01 |
Message-ID: | BANLkTin_sRVtO7UfO24ZEAzVOU0eh79ErA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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?
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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2011-05-23 18:57:27 | Re: [BUGS] BUG #6034: pg_upgrade fails when it should not. |
Previous Message | Robert Haas | 2011-05-23 18:49:29 | Re: Pull up aggregate subquery |