From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
---|---|
To: | Daniel Verite <daniel(at)manitou-mail(dot)org> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Trouble with FETCH_COUNT and combined queries in psql |
Date: | 2019-04-23 20:07:05 |
Message-ID: | alpine.DEB.2.21.1904232201260.3407@lancre |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>> 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.
>
> Looking at the end of the discussion about \cset, it seems what
> you were against was not much how the detection was done rather
> than how and why it was used thereafter.
>
> In the case of the present bug, we just need to know whether there
> are any \; query separators in the command string.
> If yes, then SendQuery() doesn't get to use the cursor technique to
> avoid any risk with that command string, despite FETCH_COUNT>0.
>
> PFA a simple POC patch implementing this.
Indeed it does not look that bad.
Note a side effect of simply counting: "SELECT 1 \; ;" is detected as
compound, but internal misplaced optimization would result in only one
result as the empty one is removed, so the cursor trick would work.
In some earlier version, not sure whether I sent it, I tried to keep their
position with some int array and detect empty queries, which was a lot of
(ugly) efforts.
--
Fabien.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2019-04-23 20:15:11 | Re: How and at what stage to stop FDW to generate plan with JOIN. |
Previous Message | Tom Lane | 2019-04-23 20:05:59 | Re: Calling PrepareTempTablespaces in BufFileCreateTemp |