Re: Dyamic updates of NEW with pl/pgsql

On Mon, Mar 15, 2010 at 12:19 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Merlin Moncure <mmoncure(at)gmail(dot)com> writes:
>> On Mon, Mar 15, 2010 at 11:37 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> If we make the implementation be such that "(rec->field)::foo" forces
>>> a runtime cast to foo (rather than throwing an error if it's not type
>>> foo already)
>
>> yeah...explicit cast should always do 'best effort'
>
> Probably so.  But is it worth inventing some other notation that says
> "expect this field to be of type foo", with an error rather than runtime
> cast if it's not?  If we go with treating the result of -> like UNKNOWN,
> then you wouldn't need that in cases where the parser guesses the right
> type.  But there are going to be cases where you need to override the
> guess without necessarily wanting to buy into a forced conversion.

Maybe. That behaves like oid vector to PQexecParams, right? Suggests
a type but does not perform a cast. I see your point but I think it's
going to go over the heads of most people...type association vs type
coercion. Maybe instead you could just supply typeof function in
order to provide very rigorous checking when wanted and presumably
allow things like pointing the assignment at a special field.

merlin