On Fri, 13 Feb 2004, Stephan Szabo wrote:
>
> On Fri, 13 Feb 2004, Tom Lane wrote:
>
> > Stephan Szabo <sszabo@megazone.bigpanda.com> writes:
> > > On Fri, 13 Feb 2004, Tom Lane wrote:
> > >> I was looking at that last night. It seems like we could add a LIMIT at
> > >> least in some contexts. In the case at hand, we're just going to error
> > >> out immediately if we find a matching row, and so there's no need for
> > >> FOR UPDATE, is there?
> >
> > > I think there still is, because a not yet committed transaction could have
> > > deleted them all in which case I think the correct behavior is to wait and
> > > if that transaction commits allow the action and if it rolls back to
> > > error.
> >
> > Good point. Okay, we can't put in a LIMIT. But we could still hack the
> > planner to prefer a fast-start plan by passing an out-of-band tuple
> > fraction, for those RI plans where it's appropriate. That would not
> > affect correctness.
>
> Right, I can try to look through the stuff you pointed at in the previous
> message over the weekend.
It looks to me that we could make this available to SPI fairly simply by
taking the current version of the following four routines: planner,
pg_plan_query, _SPI_execute and SPI_prepare, renaming them and giving them
a planning tuple fraction as a parameter, change references to the other
routines to the new names and then making four new functions with the
current names that call the renamed versions. In all the cases other than
planner I think we can have the new version pass 0.0 and in the case of
planner either 0.1 or 0.0 based on the isCursor parameter.