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 1umUOB-00GVjc-EV for pgadmin-hackers@arkaria.postgresql.org; Thu, 14 Aug 2025 09:36:51 +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 1umUO9-004T84-OT for pgadmin-hackers@arkaria.postgresql.org; Thu, 14 Aug 2025 09:36:49 +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 1umUO9-004T7w-CZ for pgadmin-hackers@lists.postgresql.org; Thu, 14 Aug 2025 09:36:49 +0000 Received: from mail-vk1-xa36.google.com ([2607:f8b0:4864:20::a36]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1umUO6-000W2s-0T for pgadmin-hackers@postgresql.org; Thu, 14 Aug 2025 09:36:47 +0000 Received: by mail-vk1-xa36.google.com with SMTP id 71dfb90a1353d-53b17378b74so305810e0c.1 for ; Thu, 14 Aug 2025 02:36:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enterprisedb.com; s=google; t=1755164205; x=1755769005; darn=postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=DBrb60nUzgegAg+Eg/Bzxz6JvnZMMCE5vNCKb+MuqMA=; b=lTySiyEtzaJ8/XL/b07XawS87cOER7ZHZTwfHDwzbY7YYUbukv1X04NJ3jGzlchz9Z HCa+smaPgUk2MNGTJXsv/nhebh7FbjKzH6V+4Y+hdb9XJofNYg5CRC9d1ys5OSp0DqmD prRkjlwruqK1sx3AQpEFEXkToaNStc5zRzTPVO+ixVmE7cHYISZoiTaSGo262soKcL5u +dXi/qgdvCq9wIBDQVq8VSqsBoYRIEjHywHCWGZQG5lIAPK4esTunLXzxylKqdfy6vj2 56qHnNEVgOaMA3khIFYzAWssoRI+sAntD8N9gVqE9rN7JgXF1GcR0YO+IZQQp64X0jrT 5noA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1755164205; x=1755769005; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=DBrb60nUzgegAg+Eg/Bzxz6JvnZMMCE5vNCKb+MuqMA=; b=nf0UWHDDq2aVtW6yIRdZc5bx6efXJVm3mr0wFZR7/jjtYei5Dn2KuMYAubHba0q5kV eCPyTsvHzP7sqWTgEr8LTegrRBWSD78D1vq+6J4EaIMTD2otBoRsnzlGTTfLU3g1UnG1 szE247HCnHt1575xK6dd4uYgVPOZtmo0bCru5G5GaaYSTfrawapJU/Jz/dzYe7wbumOT BR6INXnWzRc4UO+74inWqVxwgW2LZBpOhvr/+8avjs1yTVOTzxsyVEdtGzgUh1VsIjjR wUmuwWN9cOW/7i+SLBagrKNGlLuDeoE1f4f6oSFcDXiuKFA77K0aQiO9+srcCDI7zsMs 5KNQ== X-Gm-Message-State: AOJu0YxCwO6DmTFjGPxffhDuF9iPA4ZntkUyWjG9jxlrOyMHXkbyXSp7 R3uxjU644jdXvoI0yILsM1c9iq4JjSiSXevveK1VvOqmj2MLkJGjRBJ7s09+fa472WYc0OCRsFz XPzI9wjU6rssZ1NO7sGKWXz5k6rwHecytTjjvm6Fn X-Gm-Gg: ASbGnctZuJRtZFjBubSzBmVCOlbNnLv9eVQoeM9cH6P6hBJZpaiOwUurmpUTrzNrDzH ggOXWceRjzEfh+30krqLrOP11VKn7okPtFkhmYAr+ny4tjIOVAfmBoWz+LXA3YfXnn41bCE+7Kt AnwkTc/qQCNQDm5mYltBiPtNHzWiHUIPQtLMGhbNBzaxkU0eNMJCjPBDwPlNYcq4WlBvB4/jjwS 32MhlKbU0K96zq9wfGgnOJkH15uzSOTGnftg0C1 X-Google-Smtp-Source: AGHT+IH2n1LCk4hEsnwinEc3loJPiywmD3IpA4CmMR6fg1D+cmsKolEhGQSwZT7PNjqoFXsKb/M6rZBC9ZxhYOuNGts= X-Received: by 2002:a05:6122:8cf:b0:539:3bb5:e4c8 with SMTP id 71dfb90a1353d-53b18b63d8bmr673098e0c.12.1755164205498; Thu, 14 Aug 2025 02:36:45 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Aditya Toshniwal Date: Thu, 14 Aug 2025 15:06:20 +0530 X-Gm-Features: Ac12FXwK3PTRIeW9hLBWnqNVkW-Bd569P8hVGH0fBInJk8rdgrpIwNQycjky8GA Message-ID: Subject: Re: Require suggestions on feature 4011 To: Pravesh Sharma Cc: pgadmin-hackers Content-Type: multipart/alternative; boundary="000000000000fdd75a063c5002a6" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000fdd75a063c5002a6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Pravesh, I think we'll have to load the binary data in the backend at least like you mentioned. It will increase memory consumption, so we'll have to make this feature preference based with clear mention of the memory requirements in the help string and by default disabled. On Thu, Aug 14, 2025 at 2:35=E2=80=AFPM Pravesh Sharma < pravesh.sharma@enterprisedb.com> wrote: > Hi Hackers, > > Any suggestions on the above issue. > > Thanks, > Pravesh > > On Fri, Aug 8, 2025 at 3:41=E2=80=AFPM Pravesh Sharma < > pravesh.sharma@enterprisedb.com> wrote: > >> Hi Hackers, >> >> I'm working on feature #4011 >> , which involves >> exporting and importing BLOB (bytea) data. I've checked its feasibility = and >> these are the challenges I'm facing: >> >> Currently, we simply return the string "binary data" for bytea columns, >> and we don't load the actual binary data at all. If we want to download >> this data, we can bring it to the cursor, but when returning it to the >> front end, we'll still send the string "binary data" Upon a user's >> request to download, we'll fetch it from the cursor and return it. >> >> The main challenge I'm facing is how we'll identify the row from which >> the download needs to happen if there's no primary key in the table. >> Additionally, keeping binary data in memory could cause performance issu= es. >> For this reason, we can make it a preference-based option. >> >> >> Please let me know your thoughts/suggestions. >> >> >> Thanks, >> >> Pravesh >> >> -- >> >> >> Pravesh Sharma >> >> Senior SDE >> >> +91 9406461406 >> >> >> enterprisedb.com >> > --=20 Thanks, Aditya Toshniwal pgAdmin Hacker | Sr. Staff SDE II | *enterprisedb.com* "Don't Complain about Heat, Plant a TREE" --000000000000fdd75a063c5002a6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Pravesh,

I think we'll have to load the binary data= in the backend at least like you mentioned. It will increase memory consum= ption, so we'll have to make this feature preference based with clear m= ention of the memory requirements in the help string and by default disable= d.

On Thu, Aug 14, 2025 at 2:35=E2=80=AFPM Prave= sh Sharma <pravesh.sh= arma@enterprisedb.com> wrote:
Hi Hackers,

Any su= ggestions on the above issue.

Thanks,
Pr= avesh

On Fri, Aug 8, 2025 at 3:41=E2=80=AFPM Pravesh Sharma <pravesh.shar= ma@enterprisedb.com> wrote:
Hi Hackers,

I'm wor= king on feature #4011, which involves exporting and importing BL= OB (bytea) data. I've checked its feasibility and these are the challen= ges I'm facing:

Currently, we = simply return the string "binary data" for bytea columns, and we = don't load the actual binary data at all. If we want to download this d= ata, we can bring it to the cursor, but when returning it to the front end,= we'll still send the string "binary data" Upon a user= 's request to download, we'll fetch it from the cursor and return i= t.

The main chall= enge I'm facing is how we'll identify the row from which the downlo= ad needs to happen if there's no primary key in the table. Additionally= , keeping binary data in memory could cause performance issues. For this re= ason, we can make it a preference-based option.


Please let me know your thoughts/suggestions= .


<= p style=3D"margin:0px;font-size:13px;line-height:normal;font-family:"H= elvetica Neue";font-size-adjust:none;font-kerning:auto;font-variant-al= ternates:normal;font-variant-ligatures:normal;font-variant-numeric:normal;f= ont-variant-east-asian:normal;font-feature-settings:normal">Thanks,

Pravesh

<= div>
--


<= tbody>

Pravesh Shar= ma

Senior SDE

+91 9406461406


<= /p>

enterprisedb.com



--
Thanks,
Aditya Toshniw= al
pgAdmin Hacker=C2=A0| Sr. Staff SDE II=C2= =A0| enterprisedb.com
"Don't Complain about Heat, Plant a TREE"
--000000000000fdd75a063c5002a6--