Andrew Dunstan <and...@dunslane.net> writes:
> This whole proposal strikes me as premature. What we need is some
> experience from the field in using DO before we can sensibly decide how
> it should be extended. And we won't get that until 9.0 has been released
> and used for a while.
+1.
What strikes me about this proposal is that there isn't any way to pass
parameter strings without worrying about how to escape them; which means
that the actual functionality gain over 9.0 is at best rather limited.
Now you could get to that if we had support for utility statements
accepting parameter symbols, ie you could execute
DO ... USING $1, $2
with out-of-line parameter values passed using the PQexecParams protocol.
So maybe that's an orthogonal feature that should be done as a separate
patch, but without it I'm not sure there's really much point.
IIRC one of the stumbling blocks for parameters in utility statements
is that usually there's no good context for inferring their data types.
If we were to extend DO in the particular way Pavel suggests, then
there would be context for that case, but I'm not sure what we do about
the general case. We'd want to think about that before installing a
special-purpose rule that only works for DO.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
