Tom Lane wrote:
BTW, rather than hacking the parameter list of ProcessUtility,
I'd be inclined to just look at ActivePortal-portalParams in
PerformCursorOpen. (Come to think of it, we could also copy
ActivePortal's sourceText at the PortalDefineQuery step.)
I've done this and it seems to work
Oliver Jowett [EMAIL PROTECTED] writes:
It seems like we should pass the original parameters from execution of
the DECLARE utility portal down through PortalRunUtility -
ProcessUtility - PerformCursorOpen, copy them into the newly created
portal's memory context, and pass the copies to
Oliver Jowett wrote:
It seems like we should pass the original parameters from execution of
the DECLARE utility portal down through PortalRunUtility -
ProcessUtility - PerformCursorOpen, copy them into the newly created
portal's memory context, and pass the copies to PortalStart on the new
Oliver Jowett [EMAIL PROTECTED] writes:
Logs follow; basically this is issuing a Parse/Bind/Execute for a
parameterized DECLARE, which blows up with no value found for parameter
1 despite there definitely being one there. (also, that error appears
on Execute, not Parse/Bind).
This may be
Tom Lane wrote:
Any chance of getting this fixed for 7.5?
I'm up to my keister in PITR and nested-xact issues and won't have time
to look at it soon. Do you want to take a look and see if you can find
where the ball is getting dropped?
Ok, I'll do that.
-O
---(end of
On Wed, 21 Jul 2004, Oliver Jowett wrote:
It's going to be fun using anything more than very basic cursors via the
V3 protocol in the JDBC driver. DECLARE does not work with parameters
passed via a Parse/Bind combination -- which is how we currently always
pass parameters when talking
