Dave Cramer <pg@fastcrypt.com> writes:
> At this point I'd just like the backend to ignore the OUT parameter if
> it were set that way, but allow it to be sent.
I think you're thinking at the wrong level. AIUI the issue occurs at
the Parse stage, long before any parameter value is sent (or not sent).
What you really want, if I'm understanding correctly, is to be able to
send SQL that looks like this:
SELECT * FROM myfunc($1,$2,$3);
and then have some of the Param symbols be simply ignored while looking
up myfunc().
This is pretty ugly in itself, and I'd not want to add a protocol change
into the mix to make it happen. But possibly we could do it without any
protocol-level change. What would you say to specifying that Params
that are declared as type VOID are ignored in a function lookup? What
this would mean is that you'd need to do the following:
1. The SQL string can look as above.
2. When sending the Parse message, you'd specify the parameter types as, say, INT4/VOID/VOID (or possibly
UNKNOWN/VOID/VOID).
3. When sending Bind, you'd have to specify dummy values (probably nulls) for the VOID parameter positions.
While I haven't looked at the backend code yet, I think we could drop
VOID-type parameters out of the argument list of a function during
parse analysis without too much trouble. This would affect *all*
function calls, not only those appearing in SELECT * FROM, but
I don't see any legitimate use of VOID-type values that this would
interfere with.
Klugy, isn't it? Anyone have a better idea? Or should we just tell
Dave that the JDBC driver ought to handle it?
regards, tom lane