> > Right now, I'm transitioning to ExexPrepared to skip the string
escaping
> > step on the client side. I would hate to lose that ability.
ExecParams
> > is a little more work to set up (doable, though).
>
> OTOH, if you're taking client code queries and replacing them with
> EXECUTEs (which I sort of gathered some people were doing), all it
should
> really do is move the matching activity to the server...
There is one subtle difference, and that the type resolution gets moved
from the server to the client. ExecParams() requires a list of type
OIDs to be sent along with the statement whereas ExecPrepared() does
not. To me, this is an inconsistent interface is set up with the
parameter name, not the oid of the parameter. To me, it makes much more
sense to resolve by type name in all cases, but this may have some
performance implications.
> But why should anyone insist on a "transaction agnostic scenario" yet
> play with prepared statements? That seems backwards to me.
Transactions
Because it improved statement turnaround by about 33%, and that's all I
really care about. The conceptual case seems outweighed by practical
matters (if you move to a transactional lifetime first, that is). This
performance difference is like having an extra processor.
> In any case, AFAICS my proposal does away with the need to wrap
anything,
> or keep track of transactions and/or prepared statements. Would it
work
> for you?
Yes, it would. It would actually make my life a lot easier
(notwithstanding my minor gripe with ExecParams) because I would no
longer have to deal with all the complexities surrounding prepared
statements. This is A Good Thing, because the optimization is generic
and thus will benefit a lot more people.
It is also more a more complex optimization model; and I think you would
have to justifiably prove that it is in the same performance league as
the current prepared statement model. Also the current prepared
statement behavior should be retained for 7.5 and perhaps deprecated if
your viewpoint wins out (and it should).
Merlin
