Prev: [HACKERS] PL/pgSQL EXECUTE '..' USING with unknown
Next: [HACKERS] LockDatabaseObject vs. LockSharedObject
From: Heikki Linnakangas on 6 Aug 2010 03:40
On 06/08/10 01:13, Tom Lane wrote:
> Andrew Dunstan<andrew(a)dunslane.net> writes:
>> On 08/05/2010 05:11 PM, Tom Lane wrote:
>>> This example doesn't seem terribly compelling. Why would you bother
>>> using USING with constants?
>
>> In a more complex example you might use $1 in more than one place in the
>> query.
>
> Well, that's better than no justification, but it's still pretty weak.
> A bigger problem is that doing anything like this will require reversing
> the logical path of causation in EXECUTE USING. Right now, we evaluate
> the USING expressions first, and then their types feed forward into
> parsing the EXECUTE string. What Heikki is suggesting requires
> reversing that, at least to some extent. I'm not convinced it's
> possible without breaking other cases that are more important.

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 patch doesn't currently check that a parameter is only resolved to
one type in the same query, but that can be added.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
First  |  Prev  | 
Pages: 1 2
Prev: [HACKERS] PL/pgSQL EXECUTE '..' USING with unknown
Next: [HACKERS] LockDatabaseObject vs. LockSharedObject