Martijn van Oosterhout <kleptog@svana.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
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
