Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1v1Oqe-008EpK-S0 for pgadmin-hackers@arkaria.postgresql.org; Wed, 24 Sep 2025 12:43:53 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1v1Oqc-00D8s3-4R for pgadmin-hackers@arkaria.postgresql.org; Wed, 24 Sep 2025 12:43:50 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1v1Oqb-00D8ru-Ov for pgadmin-hackers@lists.postgresql.org; Wed, 24 Sep 2025 12:43:49 +0000 Received: from mail-vs1-xe2a.google.com ([2607:f8b0:4864:20::e2a]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1v1OqY-002BM7-09 for pgadmin-hackers@postgresql.org; Wed, 24 Sep 2025 12:43:47 +0000 Received: by mail-vs1-xe2a.google.com with SMTP id ada2fe7eead31-55716f2d3b9so5169318137.1 for ; Wed, 24 Sep 2025 05:43:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enterprisedb.com; s=google; t=1758717825; x=1759322625; darn=postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=iFRIJnK7Ic4t489a/asVh8T71OpFQxH+SeqToIh0mgU=; b=IopYIF+CxP8nVWYUYGoC1+sbFSEqptDWbLsxTCjRf1HM6h6PTc3RTj2QE8GWMn4lm/ 47SaZkxFHMJqFiCFJawBcdmigDOuWT9QLu+goVKDt9+f5pD3C2lSZdwUyKj4zdnMtQdc 4w9IldxlToCjyAFdIMblmS1Eoad3Ot0BIIy+wfYbzo4aOcaNVop4E64r584Oend2e422 SBKHqmCMPQvzD2YL+UjM3XGNc0NiKdukR6/76PJxrUWQfjo2F+lulKZQivkT6/vLYKEe DP1RHu44lT8ZyWCY2oIht6Y5KTI+3d5zRvLxtgH+dRsP2H/7D+lB0X+ZuxeNgNz0x29y nbOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1758717825; x=1759322625; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=iFRIJnK7Ic4t489a/asVh8T71OpFQxH+SeqToIh0mgU=; b=UyMqEvGBF1tF1U9pRe8cHZbzVg5LDvESnQjAsFJvar4r0d4E6SY2vv08cTkA6BDgvA X/nPxfJzLvpJDQL6sr1BTpwn9fGQxNF2v2Jf+wE/Gcb/R5LytaUesA8vPIKXPC+54Rfl nEMZ/pKVXHmtj4zPhvldKtiQdPLcq2fdwUDIzp5HIelFzDqRGYGNqr0PQP64aNZl4AuI T7l/EczvhelxyOJdFq30ENYIdiLNRv9J2Mx+YLJkep5tP8eKyGxpgL5Sdv0UKOuyeg9y BZdTlQencWd4+3o8t8km/+DO2ChVr2bxb9yNkfjRto+WTjw6MZlgNWkBPavNzvONQOPs tmRQ== X-Gm-Message-State: AOJu0Yy6M7Wn1J50RvWQnZDzT/RRbWozWHM9Fa2GdTLI6Ui3L8wQdmiB 3pzkD7qXkcnmZea35kBtxyWXVWkbSEg3CXYBjcgSw7UxMnNm/nZf2wCekB7getMsVhsk0hf6xIN R2ay18OogWOpKA7ERVNtYF5md5IeunK55DKGZSJd0g7TwTUEHQFY= X-Gm-Gg: ASbGncshZKaO1Ki8tDKfSDKCSoaB/lFtUPFNCtceAC3LU4XQjoy+I+9yOuC8rDOH2zA njl3qOhAsDgDATthSYRqmu1JSLtOIWDfGb25oKIgGe4XK7IiPh2FCjH+SpG9ovD9bm4KhP5/VfZ qy9UmEbHm0MCK8PzDrvBrqsYOepF51uhDnHwH3owk68bw/eB2nIF2VpshzmfSL3E91OEevTszPF q1ZVhgdGQ== X-Google-Smtp-Source: AGHT+IEzZxWE7tt+sGD//u/jBsG1YmvCFp4w00zjOIjaheWx4z838tyJQ4ipv7qOsvcpGbNLbeezS/k9PBqhm9+x/sQ= X-Received: by 2002:a05:6102:80a2:b0:524:5266:f74c with SMTP id ada2fe7eead31-5a582ed2ee8mr2346701137.31.1758717824697; Wed, 24 Sep 2025 05:43:44 -0700 (PDT) MIME-Version: 1.0 From: Aditya Toshniwal Date: Wed, 24 Sep 2025 18:13:15 +0530 X-Gm-Features: AS18NWAjkNkjV2bnrgVp_Egp16OcPuwdIxExzd-2qdejoQzZAORqkKOqIzJXE7g Message-ID: Subject: Regarding multiple result set in query tool To: pgadmin-hackers Content-Type: multipart/alternative; boundary="0000000000003397fb063f8b6752" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000003397fb063f8b6752 Content-Type: text/plain; charset="UTF-8" Hi Dave/Hackers, I'm working on a feature where the query tool will show separate data output for all the select statements run in a single batch. psycopg does provide the result sets (as libpq provides) but there is a catch. Let me explain how pgAdmin currently works: 1. psycopg provides a cursor object on query execution. 2. The cursor object has a function called nextset which can be used to move to the next result set of queries executed. 3. Once you move to the nextset, you cannot get data for the previous set. It will only point to the current set. 4. Right now, we keep on looping through nextset until it reaches the last set and then fetch the data from the last set (using pagination). 5. The fetched result is stored in client memory (python process) So if we need to show the output of all the queries, we'll have to fetch the result for each query and store it in python memory before moving to the next set. psycopg already stores the data on the client side, the only difference will be that we'll store all sets and not just the last one. If any one has any suggestions on memory management then please let me know. Otherwise, I'm proceeding with what is discussed above. Note: This will not be applicable for server cursors as it will against the whole point of server cursor. -- Thanks, Aditya Toshniwal pgAdmin Hacker | Sr. Staff SDE II | *enterprisedb.com* "Don't Complain about Heat, Plant a TREE" --0000000000003397fb063f8b6752 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Dave/Hackers,

I'm working on a feat= ure where the query tool will show separate data output for all the select = statements run in a single batch. psycopg does provide the result sets (as = libpq provides) but there is a catch. Let me explain how pgAdmin currently = works:
1. psycopg provides a cursor object on query execution.
2. The curso= r object has a function called nextset which can be used to move to the nex= t result set of queries executed.
3. Once you move to the nextset, you ca= nnot get data for the previous set. It will only point to the current set.<= /div>
= 4. Right now, we keep on looping through nextset until=C2=A0it reaches the = last set and then fetch the data from the last set (using pagination).
5. T= he fetched result is stored in client memory (python process)

So if we= need to show the output of all the queries, we'll have to fetch=C2=A0t= he result for each query and store it in python memory before moving to the= next set.
psycopg already stores the data on the client side, the only dif= ference will be that we'll store all sets and not just the last one.
If any one has any suggestions on memory management then please let me k= now.
Otherwise, I'm proceeding with what is discussed above.

=
Note:= This will not be applicable for server cursors as it will against the whol= e point of server cursor.

--
Thanks,
Ad= itya Toshniwal
pgAdmin Hacker=C2=A0| <= font size=3D"2" color=3D"#000000" face=3D"arial, sans-serif">Sr. Staff SDE = II=C2=A0|<= font color=3D"#0c343d"> enterprisedb.com
"Don't Complain about Heat, Plant a TREE"=
--0000000000003397fb063f8b6752--