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.98.2) (envelope-from ) id 1x9elS-000000029Lt-1Hwy for pgsql-general@arkaria.postgresql.org; Thu, 24 Sep 2026 08:25:11 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.98.2) (envelope-from ) id 1x9elR-0000000AG5i-2JaC for pgsql-general@arkaria.postgresql.org; Thu, 24 Sep 2026 08:25:09 +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.98.2) (envelope-from ) id 1x9elQ-0000000AG5Z-1JGK for pgsql-general@lists.postgresql.org; Thu, 24 Sep 2026 08:25:09 +0000 Received: from omr-01.pc5.atmailcloud.com ([103.150.252.181]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1x9elM-00000000zj9-0G9A for pgsql-general@postgresql.org; Thu, 24 Sep 2026 08:25:06 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tpg.com.au; s=202309; h=MIME-Version:Content-Type:Date:To:From:Subject:Message-ID; bh=+Fc1loQXoCsnlphd/uiik0ReVQbAvm7hgOOcyvIvXGI=; b=JGacMavna6uqL2t5dI/e88focC tgm8MpE5cXkZUXAKXmqHBbmPzl2+6ah8NCkadYXcFtRzvn15RwX3gN81LAb3ID273OQX860/ZOq/b gubpH+Ildzj2wdA3016oME7B/8/8qPvGYNURmIQkjcm3sSwP2w3Xz8iwDRfSYTt+7iIiWz/6Go/Y8 2dmXALoMd4l5tl4JehIwjl47VIe45PwV0Ldc8N0WqF0LBvyAucrytNTSMYUPeWe7nJ1/9NqYj+3J3 qjUL9Dp70yj3TZeKmhdhr7Q1hPa/JxSR+0t1WRrk5ZKnNMb8lL8M6f8PBrf9uDQT9AYmjKju22/y1 FpEth7KQ==; Received: from cmr-kakadu02.internal.pc5.atmailcloud.com (cmr-kakadu02.internal.pc5.atmailcloud.com [192.168.1.4]) by omr-01.pc5.atmailcloud.com (Exim/cmr-kakadu02.i-0c97699c2d00d22cd) with ESMTPS (envelope-from ) id 1x9elJ-00000001rUS-1q3o for ; Thu, 24 Sep 2026 08:25:01 +0000 Received: from [115.128.182.15] (helo=[192.168.1.103]) by cmr-kakadu02.i-0c97699c2d00d22cd with esmtpsa (envelope-from ) id 1x9elH-0000000C2mz-33zm for pgsql-general@postgresql.org; Thu, 24 Sep 2026 08:25:01 +0000 Message-ID: <12e2ffff149842d8762774e8ef307743cdb96736.camel@tpg.com.au> Subject: Multiple schemas From: rob stone To: pgsql-general@postgresql.org Date: Thu, 24 Sep 2026 18:24:58 +1000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.56.2-10 MIME-Version: 1.0 X-Atmail-Id: floriparob@tpg.com.au Authentication-Results: cmr-kakadu02.au-east.atmailcloud.com; auth=pass smtp.auth=floriparob@tpg.com.au X-atmailcloud-spam-action: X-atmailcloud-route: unknown List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hello, I've been using a single schema in a database for years and I decided to try using multiple schemas in the same database. So, I set up a test database and followed the same procedure that I have used in the past but this time specifying multiple schemas. O/S Linux 7.2.6+deb14-amd64 #1 SMP PREEMPT_DYNAMIC Debian 7.2.6-1 (2026-09- 16) x86_64 GNU/Linux Postgres psql (18.6 (Debian 18.6-3)) \dn List of schemas Name | Owner =20 --------+------------------- bsmdl | teamone foots | teamone public | pg_database_owner (3 rows) show search_path; search_path =20 ---------------- "bsmdl, foots" (1 row) A \dn runs a query against the catalogue whereas "show search_path" displays what was obtained from the connection. I ran a create table script where all tables were fully qualified schema.table_name and it completed without any errors. Then I ran:- \d system_defaults (one of the newly created tables) and this was the result:- Did not find any relation named "system_defaults". select * from pg_tables where tablename =3D 'system_defaults'; schemaname | tablename | tableowner | tablespace | hasindexes | hasrules | hastriggers | rowsecurity=20 ------------+-----------------+------------+--------------+------------ +----------+-------------+------------- bsmdl | system_defaults | teamone | basemodldata | f =20 | f | t | f (1 row) I don't know why "hastriggers IS TRUE" as there are none. According to 5.10.3 in the doco:- "The first schema named in the search path is called the current schema. Aside from being the first schema searched, it is also the schema in which new tables will be created if the CREATE TABLE command does not specify a schema name." When you run a \d table_name the first query that it runs to obtain pg_catalog.pg_class c.oid is the same if the database contains a single schema or multiple schemas. So in my test it should have looked first in schema bsmdl and if it didn't find the table it should have looked in the next schema in the search_path, and so on. According to the doco you can have tables with the same name appearing in multiple schemas, and it is the sequence in which schemas are defined in the search path which determines which one is accessed unless you specify the schema name. So, I'm doing something wrong with this set-up. If anybody else is using multiple schemas could you advise what you did that was different to having just a single schema. TIA, Rob =20