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 1s1sw0-00FhPr-UF for pgsql-general@arkaria.postgresql.org; Tue, 30 Apr 2024 19:14:36 +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 1s1svy-00876e-Bj for pgsql-general@arkaria.postgresql.org; Tue, 30 Apr 2024 19:14:35 +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 1s1svy-00876V-0j for pgsql-general@lists.postgresql.org; Tue, 30 Apr 2024 19:14:34 +0000 Received: from mail-oo1-xc2b.google.com ([2607:f8b0:4864:20::c2b]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1s1svw-000tLu-4Q for pgsql-general@lists.postgresql.org; Tue, 30 Apr 2024 19:14:34 +0000 Received: by mail-oo1-xc2b.google.com with SMTP id 006d021491bc7-5ad2da2196aso3937963eaf.2 for ; Tue, 30 Apr 2024 12:14:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1714504470; x=1715109270; darn=lists.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=7AlN3Z+4jU3m/PKkDJMHGYLFZnW0psjb8yDMdVVgRTQ=; b=ZlnpYcJkHYK7yuHrB3+6H9wyJNRfYXl7ZVQcufbJy2owhLB9YQIt3yIvBlJimP8TZO rScU7G7+AC035KF74LXuzH2HYi3tWE0NEgf0/W6i+48A1+PpaDoezweBq7Yv4qlgfkcZ fGwfxycVxCG7KDMRuvLwmkfulG39nyNsXxixVEJHRA/6vB5B3zyEGgpI6HopU1Vx2RtC XF0HU+2Tei3pXCv0a8ER7BN33vtPGSg8jUCxmrjZFbrDcBNO3mOb9jMT490oNZ7LBJiS vMsNU5sMX1jJu/FPGSdOgnoNlpr8dF5C7Ho0kWcI0Uv/rhWRJftgPwykXN5Tz4+5Xfg3 yZ/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714504470; x=1715109270; 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=7AlN3Z+4jU3m/PKkDJMHGYLFZnW0psjb8yDMdVVgRTQ=; b=UE0E3xYPemj98KZ+znljF/ddXMcXtz4sJlEiINTjdTAHCfJUoaDQbs4ioXZAkAJi86 kw2sne1pX+9c6X06eA9tqIcn+bKb5ODUUs+bW36mzU199l16KksBI9AZuwjgYs929bzF JcE2/xdscTkJIggZSE6rQu3+SkgZ+SWUspDPYGt3So0NkvikCzc2pRtncPzblNyXGNIw MoudogzcWLrRt5JRcJvmP1Cxfl9gnZeWx+Q6GD3JSLJSblcdDYB/YLqXSM9iULTFWUCO X/zlv5HFj10zl8lPpNY439LKaEJ1oHzvR2RhXaJ5SL1UxFTu1XRzxDSAPWjUsySgPa5B Qbag== X-Gm-Message-State: AOJu0YyRURl9xbljJL5sFafPs4yz76H8mAkSVUoK2DwTwDicuySx/ebK H/PRiDkUZcFdHuhSsQ/+I20PC+aGs4EV+vtFbDU2UUinJ4SEZLDL3g7H1N0mdXhJGFH+LVA4qbj 39qTnKo0+qwuWxO5t/8ZFy/gCmTzZKfcx X-Google-Smtp-Source: AGHT+IHcstashSY1RQh+wMx0OuhIcbZrkL1p+H8M+yoHIjBoBcf1Mhby5xRkNY4/by7r02JhvE1jtx2j+O40uEaRdjA= X-Received: by 2002:a4a:606:0:b0:5ac:9f5f:fbdf with SMTP id 6-20020a4a0606000000b005ac9f5ffbdfmr373939ooj.4.1714504469943; Tue, 30 Apr 2024 12:14:29 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "David G. Johnston" Date: Tue, 30 Apr 2024 12:13:52 -0700 Message-ID: Subject: Re: Introduction of a new field in pg_class indicating presence of a large object in a table To: Gaurav Pant Cc: pgsql-general@lists.postgresql.org Content-Type: multipart/alternative; boundary="000000000000e59df50617552d4d" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000e59df50617552d4d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Apr 30, 2024 at 11:57=E2=80=AFAM Gaurav Pant wrote: > I wanted to know if there is any such system table that we can use to > identify and map the fields containing large objects and the respective > tables and if it is not already there, do we have any plans to incorporat= e > the same in pg_class like we have for pg_toast? > > https://www.postgresql.org/docs/current/catalog-pg-largeobject.html Large Objects are nothing like TOAST. There is no system level association between large objects and tables. Sure, the DBA can choose to store a large object OID in a table, but how you'd go about figuring out which columns contain those is going to be installation specific. Though hopefully they used a bigint data type and maybe added "oid" to the column name...I suppose it would be interesting if one could define a FK on a table and point it at pg_largeobject_metadata but that I suspect would be the extent to which we'd do something along the lines of your request. David J. --000000000000e59df50617552d4d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Apr 30, 2024 at 11:57=E2=80=AFAM Gaurav Pant <<= a href=3D"mailto:gauravpant145@gmail.com">gauravpant145@gmail.com> w= rote:
I wanted to know if the= re is any such system table that we can use to identify and map the fields = containing large objects and the respective tables and if it is not already= there, do we have any plans to incorporate the same in pg_class like we ha= ve for pg_toast?


=

Large Objects are nothing like TOAST.=C2=A0 There= is no system level association between large objects and tables.=C2=A0 Sur= e, the DBA can choose to store a large object OID in a table, but how you&#= 39;d go about figuring out which columns contain those is going to be insta= llation specific.=C2=A0 Though hopefully they used a bigint data type=C2=A0= and maybe added "oid" to the column name...I suppose it would be = interesting if one could define a FK on a table and point it at pg_largeobj= ect_metadata but that I suspect would be the extent to which we'd do so= mething along the lines of your request.

David J.

--000000000000e59df50617552d4d--