On 16/08/10 03:35, Tom Lane wrote:
> Heikki Linnakangas<heikki.linnakangas@enterprisedb.com> writes:
>> One approach is to handle the conversion from unknown to the right data
>> type transparently in the backend. Attached patch adds a
>> coerce-param-hook for fixed params that returns a CoerceViaIO node to
>> convert the param to the right type at runtime. That's quite similar to
>> the way unknown constants are handled.
>
> The idea of using a coerce_hook instead of inventing several new API
> layers is attractive, but have you checked that there are no callers
> for which this would be a bad idea?
That code is used in a lot of different contexts, but I can't see any
where this could cause a problem. In general, I can't think of a case
where we would want to throw an error on an unknown parameter where we
accept an unknown constant at the same location. Completely rejecting
unknown parameters might make sense in some contexts, but that's not the
current behavior either, unknown parameters are accepted in some contexts.
> Another issue is that this fails to mimic the usual varparams behavior
> that a Param of unknown type should be resolved to only one type when it
> is referenced in multiple places. I'm not sure that that's a critical
> behavior, but I'm definitely not sure that it's not.
Yeah, that's exactly what I was referring to when I said:
> The patch doesn't currently check that a parameter is only resolved to one type in the same query, but that can be
added.
I'll add that check. Better to be conservative and relax it later if
needed, than to be lenient now and regret it later.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
