Re: Prepared statements considered harmful

Martijn van Oosterhout <kleptog(at)svana(dot)org> writes:
> So what are the options now? A GUC like so:
> prepare_means_plan = [true|false]
> So then a prepare will always parse straightaway, but you can choose
> whether or not you want to plan straightaway or at bind time.

That seems like just a kluge, as you'd typically want query-by-query
control, and a GUC setting isn't convenient for that.

It's entirely possible that the current protocol definition is Good
Enough, assuming that client-library designers are aware of the
implications of using named vs unnamed statements (which I bet not
all of 'em are). You *can* have either behavior today, so far as
client-issued queries go. The area that seems to need work more
drastically is controlling what happens with queries inside plpgsql.

regards, tom lane