On Fri, Feb 26, 2016 at 4:37 PM, Robert Haas <robertmh...@gmail.com> wrote: > > On Thu, Feb 25, 2016 at 1:09 PM, Robert Haas <robertmh...@gmail.com> wrote: > > On Thu, Feb 25, 2016 at 8:53 AM, Amit Kapila <amit.kapil...@gmail.com> wrote: > >>> But if the user says > >>> they want to PREPARE the query, they are probably not going to fetch > >>> all rows. > >> > >> After PREPARE, user will execute the statement using EXECUTE and > >> I don't see how user can decide number of rows to fetch which can > >> influence the execution. Can you please elaborate your point more > >> and what is your expectation for the same? > > > > Argh. I'm getting confused between prepared statements and cursors. > > So if the user does PREPARE followed by EXECUTE, then that is OK. The > > problem is only if they use DECLARE .. CURSOR FOR, which your patch > > doesn't affect. > > > > So, committed. > > And, I'm going to revert this part. If you'd run the regression tests > under force_parallel_mode=regress, max_parallel_degree>0, you would > have noticed that this part breaks it, because of CREATE TABLE ... AS > EXECUTE. >
I will look into it. With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
