вс, 1 мар. 2020 г. в 22:26, Tom Lane <tgl@sss.pgh.pa.us>:
>
> Konstantin Knizhnik <k.knizhnik@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
