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 1ukK4w-000zjT-7Y for pgadmin-hackers@arkaria.postgresql.org; Fri, 08 Aug 2025 10:12:02 +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 1ukK4r-00Ctem-An for pgadmin-hackers@arkaria.postgresql.org; Fri, 08 Aug 2025 10:11:57 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1ukK4r-00Ctcs-1K for pgadmin-hackers@lists.postgresql.org; Fri, 08 Aug 2025 10:11:57 +0000 Received: from mail-ej1-x642.google.com ([2a00:1450:4864:20::642]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1ukK4n-001QDy-0I for pgadmin-hackers@postgresql.org; Fri, 08 Aug 2025 10:11:55 +0000 Received: by mail-ej1-x642.google.com with SMTP id a640c23a62f3a-ae6f8d3bcd4so381324566b.1 for ; Fri, 08 Aug 2025 03:11:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enterprisedb.com; s=google; t=1754647911; x=1755252711; darn=postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=Y4EoV+RTd/D1Xwh+MwzZ1eZC1WsKlz8s/9BK45pFfyI=; b=K1KznYp86tBulGAHx3rthaS7gGdEik1B1iKRTgczsAYkU7+hi6wwHxpC+eW6TO4NxY 6L9Iztai40wBnt5/oB2cN1GfiSUMxvy7zyDY7Xb8Rr5QjHGFxm0E6N9mgNxt3VJkJPLg 39l5nM2LK4bhM8s1MmnXrB0oyEDG3hO7G0uk5FFG0z+51FYm62lCnJVgohnX4JxLWgBo q8ll5FR8YnIuW/p1of/ZJcGXu7jSxdKd+SExMT4ZqrFXqoqj4GbaLugSy54W8oFuU7zk p4audM2OnnQcaComIrBoLSNUeHOb+erXjdhhunEQcU3Id89DrIjHC4bBWnMZ0y6w14bg T+JA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1754647911; x=1755252711; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=Y4EoV+RTd/D1Xwh+MwzZ1eZC1WsKlz8s/9BK45pFfyI=; b=PGM7k+geSGOZj1oDTcaCx42VrB/h5L5belIueKyNMJhkfFAHY6JDZvI3y2O8EIZpAg VgyPj2wPKixUjhcwZRzvI+LpWkBOTAtlVai2hyOfYJ+qTc7vhY4IqB8HTDuSOxA7xox1 FeQxPE0VlqycRFOsLvZdKQj0CpYbItHsGAB2KjZfFbvKl0V53hy5spHeH4vI4ZLWWPHq dqi/wLdMOYk7px/tjR6b+8UMNrqPpA/2Gew1oTc5Moa6hXZApTPlscKTgsVeMO6aZrhd ca0cuiDOKDlQRq8u93ht+h/CiY1F49LaWOjdjckdojWroB35nCbPXFJ/Stp4MFQixhAw +Iog== X-Gm-Message-State: AOJu0YzT/zLKhAm+FR0HTy6zXCGQNV57dF4V7ER82s0aU9ek5enFYnMG DQGFMD7USG6kY0MR8Gl7aH2PJF/Q9B5JJ+wdGe0xaBslNeHQKFe+DhEp2xr+JEEtTQgRDPRcs/z kpWi0xZu7liOhEu/vGDjriDMD7ccUDE3Lll64KdI1YOMhPPLZwmbEsCf5IU0= X-Gm-Gg: ASbGnct3ESxjZ76bgghT1N31S/iZxUtIQbyRGZj+NVqVTfJvzlEbAGaSY9gWKrw/P0f heCSmsCAHhVNJlPRkfWyXrDl+Cl760Yk9YVL+0CeThsSO1zubQouEZC4kc5QbzbLze5BV+85kej or+HDeXJSle/DSYF0N66BCllxy5+68v4kgdknC2sN7BurDpYGZRSGdk1wPTt0ARokEeHAK+3mfr WRTfwSw X-Google-Smtp-Source: AGHT+IGM+LOek/8DMZFs/+MtyY7gQkVWITO6+SjsVzRBKHKP/5smKSbQBzJ6e3ph15FQeBbLsLxEmRUYvYdS+aDvAGw= X-Received: by 2002:a17:907:8688:b0:ae3:caba:2c07 with SMTP id a640c23a62f3a-af9c6349e68mr217642466b.18.1754647911279; Fri, 08 Aug 2025 03:11:51 -0700 (PDT) MIME-Version: 1.0 From: Pravesh Sharma Date: Fri, 8 Aug 2025 15:41:39 +0530 X-Gm-Features: Ac12FXx3aZKqnU0dDUhj1_ocADoUXbzDpQOupxAkyeOB77LdCCd_zkDmrVgLJFQ Message-ID: Subject: Require suggestions on feature 4011 To: pgadmin-hackers Content-Type: multipart/alternative; boundary="000000000000755778063bd7cd07" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000755778063bd7cd07 Content-Type: text/plain; charset="UTF-8" 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 issues. 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 --000000000000755778063bd7cd07 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Hackers,

I'm working on feature #4011, whi= ch 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 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>
--

=


Pravesh Sharma

Senior SDE

+91 9406461406


enterprisedb.com

--000000000000755778063bd7cd07--