"Daniel Verite" <dan...@manitou-mail.org> writes:
> Fabien COELHO wrote:
>> I added some stuff to extract embedded "\;" for pgbench "\cset", which has
>> been removed though, but it is easy to add back a detection of "\;", and
>> also to detect select. If the position of the last select is known, the
>> cursor can be declared in the right place, which would also solve the
>> problem.
> Thanks, I'll extract the necessary bits from your patch.
> I don't plan to go as far as injecting a DECLARE CURSOR inside
> the query, but rather just forbid the use of the cursor in
> the combined-queries case.
Keep in mind that a large part of the reason why the \cset patch got
bounced was exactly that its detection of \; was impossibly ugly
and broken. Don't expect another patch using the same logic to
get looked on more favorably.
I'm not really sure how far we should go to try to make this case "work".
To my mind, use of \; in this way represents an intentional defeat of
psql's algorithms for deciding where end-of-query is. If that ends up
in behavior you don't like, ISTM that's your fault not psql's.
Having said that, I did like the idea of maybe going over to
PQsetSingleRowMode instead of using an explicit cursor. That
would represent a net decrease of cruftiness here, instead of
layering more cruft on top of what's already a mighty ugly hack.
However ... that'd require using PQsendQuery, which means that the
case at hand with \; would result in a server error rather than
surprising client-side behavior. Is that an acceptable outcome?
regards, tom lane
