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.96) (envelope-from ) id 1va2NA-002js0-2N for pgsql-general@arkaria.postgresql.org; Mon, 29 Dec 2025 01:48:37 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1va2N9-00EvR4-27 for pgsql-general@arkaria.postgresql.org; Mon, 29 Dec 2025 01:48:36 +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.96) (envelope-from ) id 1va2N9-00EvQw-0f for pgsql-general@lists.postgresql.org; Mon, 29 Dec 2025 01:48:36 +0000 Received: from mail-oo1-xc36.google.com ([2607:f8b0:4864:20::c36]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1va2N8-0036Ri-1m for pgsql-general@lists.postgresql.org; Mon, 29 Dec 2025 01:48:35 +0000 Received: by mail-oo1-xc36.google.com with SMTP id 006d021491bc7-65d132240acso4867881eaf.1 for ; Sun, 28 Dec 2025 17:48:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1766972913; x=1767577713; darn=lists.postgresql.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=gfVTshufZ0QqCUk4GgBZtT8e1w57S0fgkoa22yoC7eA=; b=jPrYa1+i2qB4A0ugYStMgg535quzQHJ2tHmxvPOqRBVL8gz5egj8dmdaiNEuokIhJr Q+tQYGgzaxOWK3Ph4J1gTxk/EAjckPfYcY9uyw2D+Tps8QVIUD2qdafBPhgxrzYml/7d PQ3xWtFoQyAkXVDa9xWg3HWuD6qcNSnobCpyL8ZpMy0E7hwbdqTtbbVFmZc04f4yTnEr PWqEMY+JQTpuf9oD1oaJgKnueGht1SWWl0cjR8LBXyHNrJA9j3J44wxYzeLhoUk/Ooml +Hmi24DnUGk2h54BZBcBXSbpw42IRE9RHA49FRZUv5BIo/oUQewkPdQcF3krozgUUCja +YEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1766972913; x=1767577713; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=gfVTshufZ0QqCUk4GgBZtT8e1w57S0fgkoa22yoC7eA=; b=YqFuvlCkWzewJxbB/rsXPnN1jzsBZmIs/wl6FeE8XprK5lsw5lGQStcL1FVtfyPmO8 FMK9+kXi2moTkvtFrZXyRPPWug9sibUbK15/YB+wann59HnF1Ue6Vorb1//8BJGbsHrt 6ZJunzyLFDnMHY2RvBHpgag4Yly73xKVomxG4YudST/JWr92iBQUkMqEyQl36NoAdQfr 26OW3LTX/mzc11HhA9Vtw2IWs2XLyWArPBoAwqZU73N70Pyv8sBdqlSN2Wd/78jqr9ht JnTnfG6QtCz+Tje05deQuK8mHQYJiJwbt5qI3q0h5fpkVtAZ5Bbv40WHCmTsZMQ8oea7 +c/A== X-Gm-Message-State: AOJu0YwxDNCJBLuz6dVlvVzZC2+YKeRkeBkvBBOKpNq6+LKTLWoyhscJ D8hYe6S4buR/vUccsGarmyxwIOHVnzVLVkdi4qdRrTgPrSqKxVGrOCaoYt6ql/VDdODy7FcmMwc Une3U0xRGd6qMATewtcQZJstN1xXqv/QRVw== X-Gm-Gg: AY/fxX6MQzHkP+m9X11qZWj9N0xU19TysZ5+0Bj6z6DoHPgbeX6jjdrtaYQHoxFHB6D kQyLbby4A7S7rLLpIhagYzrxs2UoBFVkQmSepxkcS/LUjiGkri1VKHPtMbZxTOi4J0pbsM7rOHU pPFwBji5w2onTXCZk/AijfdW1a7Ptg9CaFBtRWEkKqIzYV9E2KEBZPBUQX+Pv5bKoZi9EQL7tot 62BYRsxLCqY3k3ViH1jJHWiYy2RSSjacIeo8cUbP/DQWzhvG3WxuKqk5rRqpqyNb6JEUBhf X-Google-Smtp-Source: AGHT+IFwzKxd5dcV6Ds5h/Ab0u/uRCfTiLR/o0vQ3kEDl8GeqJk2H9nPqbkpJGu1BszSuDqxB9tOKT53pbH/LeSAy5c= X-Received: by 2002:a05:6820:6283:b0:659:9a49:9040 with SMTP id 006d021491bc7-65d0e94d580mr9452295eaf.11.1766972913354; Sun, 28 Dec 2025 17:48:33 -0800 (PST) MIME-Version: 1.0 References: <8254F175-871C-4678-8D28-A67E09B099A6@meddatainc.com> In-Reply-To: <8254F175-871C-4678-8D28-A67E09B099A6@meddatainc.com> From: Ron Johnson Date: Sun, 28 Dec 2025 20:48:22 -0500 X-Gm-Features: AQt7F2oNgTI-bwRR7kvxwnnGMlHdMcpC13vYbBE9_sDx5RF4Mlz4s52y1T2Z_SI Message-ID: Subject: Re: Combining metavariables and table names To: PostgreSQL Users Mailing List Content-Type: multipart/alternative; boundary="000000000000d40af906470d7049" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000d40af906470d7049 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Dec 28, 2025 at 8:39=E2=80=AFPM H wrote: > Running postgresql 16 on Rocky Linux 9 developing a multi-tenant > application where tenants will be represented by individual schemes. > > I am using the temporal tables extension to save updated/deleted rows and > am running into a problem. During the development I am creating tables in > an SQL files for testing. In my example, the SQL files also create a > versioning trigger for the example table test using test_history to store > updated/deleted rows using the following statements: > > Metavariable to store schema: > > \set s t > > ... > > CREATE OR REPLACE TRIGGER versioning_trigger > BEFORE INSERT OR DELETE OR UPDATE > ON :s.test > FOR EACH ROW > EXECUTE PROCEDURE public.versioning('sys_period', ':s.test_history', > 'true'); > > Creating the tables works as expected, as does inserting data into them. > However, updating/deleting rows the following generates the error message > "ERROR: schema ":s" does not exist" even though it does exist. I have > tried different variations of ':s.test_history' such as :"s"'.test_histor= y" > and a number of other variations, none of which work for the > update/deletion of a row. > > The only way I have gotten it to work is to add the following statement t= o > the SQL file creating tables: > > \set stest :s'.test_history' > > and then to reference it like: > > CREATE OR REPLACE TRIGGER versioning_trigger > BEFORE INSERT OR DELETE OR UPDATE > ON :s.test > FOR EACH ROW > EXECUTE PROCEDURE public.versioning('sys_period', :"stest", 'true') > > Note the placement of the colon and the use of trouble quotes. > > I have a feeling I might be missing how to use the combination of a > metavariable and a table name when used in an argument to a procedure. > > Even though I gotten it to work, what would the correct usage be? > If you can't get it to work the way you want it to, there's always bash string variable substitution. I use that extensively. The benefit is keeping all the code in one file instead of spreading it across (possibly multiple) .sql files in addition to the shell script. --=20 Death to , and butter sauce. Don't boil me, I'm still alive. lobster! --000000000000d40af906470d7049 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Dec 28, 2025 at 8:39=E2=80=AFPM H= <agents@meddatainc.com>= wrote:
Running postgresql 16 on Rocky Linux 9= developing a multi-tenant application where tenants will be represented by= individual schemes.

I am using the temporal tables extension to save updated/deleted rows and a= m running into a problem. During the development I am creating tables in an= SQL files for testing. In my example, the SQL files also create a versioni= ng trigger for the example table test using test_history to store updated/d= eleted rows using the following statements:

Metavariable to store schema:

\set s t

...

CREATE OR REPLACE TRIGGER versioning_trigger
=C2=A0 =C2=A0 BEFORE INSERT OR DELETE OR UPDATE
=C2=A0 =C2=A0 ON :s.test
=C2=A0 =C2=A0 FOR EACH ROW
=C2=A0 =C2=A0 EXECUTE PROCEDURE public.versioning('sys_period', = 9;:s.test_history', 'true');

Creating the tables works as expected, as does inserting data into them. Ho= wever, updating/deleting rows the following generates the error message &qu= ot;ERROR:=C2=A0 schema ":s" does not exist" even though it d= oes exist. I have tried different variations of ':s.test_history' s= uch as :"s"'.test_history" and a number of other variati= ons, none of which work for the update/deletion of a row.

The only way I have gotten it to work is to add the following statement to = the SQL file creating tables:

\set stest :s'.test_history'

and then to reference it like:

CREATE OR REPLACE TRIGGER versioning_trigger
=C2=A0 =C2=A0 BEFORE INSERT OR DELETE OR UPDATE
=C2=A0 =C2=A0 ON :s.test
=C2=A0 =C2=A0 FOR EACH ROW
=C2=A0 =C2=A0 EXECUTE PROCEDURE public.versioning('sys_period', :&q= uot;stest", 'true')

Note the placement of the colon and the use of trouble quotes.

I have a feeling I might be missing how to use the combination of a metavar= iable and a table name when used in an argument to a procedure.

Even though I gotten it to work, what would the correct usage be?

If you can't get it to work the way you want= it to, there's always bash string variable substitution.=C2=A0 I use t= hat extensively.=C2=A0 The benefit is keeping all the code in one file inst= ead of spreading it across (possibly multiple) .sql files in addition to th= e shell script.

--
Death to <Redacted>, and butter sauce.
Don't boil me, I&= #39;m still alive.
<Redacted> lobster!
=
--000000000000d40af906470d7049--