вс, 1 мар. 2020 г. в 22:26, Tom Lane <t...@sss.pgh.pa.us>: > > Konstantin Knizhnik <k.knizh...@postgrespro.ru> writes: > > [ autoprepare-extended-4.patch ] > > The cfbot is showing that this doesn't apply anymore; there's > some doubtless-trivial conflict in prepare.c. > > However ... TBH I've been skeptical of this whole proposal from the > beginning, on the grounds that it would probably hurt more use-cases > than it helps. The latest approach doesn't really do anything to > assuage that fear, because now that you've restricted it to extended > query mode, the feature amounts to nothing more than deliberately > overriding the application's choice to use unnamed rather than named > (prepared) statements. How often is that going to be a good idea? > And when it is, wouldn't it be better to fix the app? The client is > likely to have a far better idea of which statements would benefit > from this treatment than the server will; and in this context, > the client-side changes needed would really be trivial. The original > proposal, scary as it was, at least supported the argument that you > could use it to improve applications that were too dumb/hoary to > parameterize commands for themselves.
The theme of this thread: - it is not possible to reliably "fix the app" when pgbouncer or internal driver connection multiplexing are used. - another widely spread case is frameworks (ORM or other). There is no way to prepare a concrete query because it is buried under levels of abstractions. Whole "autoprepare" thing is a workaround for absence of "really trivial client-side changes" in these conditions. regards, Yura