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 1suf8C-008dTB-6Y for pgsql-general@arkaria.postgresql.org; Sat, 28 Sep 2024 21:37: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 1suf8A-00DfdF-Gc for pgsql-general@arkaria.postgresql.org; Sat, 28 Sep 2024 21:37:34 +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 1suf8A-00Dfd1-2t for pgsql-general@lists.postgresql.org; Sat, 28 Sep 2024 21:37:34 +0000 Received: from mail-oa1-x29.google.com ([2001:4860:4864:20::29]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1suf86-001a40-6h for pgsql-general@lists.postgresql.org; Sat, 28 Sep 2024 21:37:33 +0000 Received: by mail-oa1-x29.google.com with SMTP id 586e51a60fabf-2871f46bb84so759195fac.2 for ; Sat, 28 Sep 2024 14:37:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1727559450; x=1728164250; darn=lists.postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=p9z4j9UMPWDtDghsSSodnTIfZWbzPwiFtYj0zH5+Ot4=; b=CuZfFhwjygrNRuWKyy/1yGR6yT1Ky4bHA8SEugALuExDAW4Lpwf+7BQ87l8qsgfbrx bEXgRa0sWibZVU9UiUAYoalpufDDL7rgNl4oTykZq4NynczY/KwDYBCc3Gisr848QFNc zIzs7cpsOgO1jG5P4pEorbCcD/LbiQNEdiEEchEoyGrnrGhWepK3zq7tP3gJZ1jcIN7v LgguFyxpO9DtSyW50/HGVJwVRr+IP3EtiyIac3I/HDWamRRzWqyF7veFSDSmDDFJgnFw rdHDQF2ubp6MESTejeFrlEbgTIUJPZI5I4MKkDQUuF1qoZTsA68eqREThIxEY5dsVYJ8 /TQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727559450; x=1728164250; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=p9z4j9UMPWDtDghsSSodnTIfZWbzPwiFtYj0zH5+Ot4=; b=AeDlO9UytvoczazvO+L0WKtdYrd/ikjvZim3ZVDbU5eJeHfz+Z+c9dObu2+4yuxpSV BjeI8YbXfFnIcGTxJlbdwuqJU9BAyG4gSn2z9U08eRFW4lnZtmQHfdzG8arDkBHvYpyI RVT+6Yr1H35/rqiGNqn7KpBVUUNdFRCfZ8hlkrk92kM9R7QNZ7+Nbl+bdhGiuT8t0Kt4 +aVEZbDD64aEiNOjHwA0PrYoBqPny/uJbtqaaYyFhAZV04H1ta2RPPpJ0FgSIjAHYeJo CjNSRj4t2pFk+J01K1OCcD0I7Fm/BFKv9kAilhXGS3FLL/8Y+LKB0Rul1gUWzRQnQALy 1pqg== X-Gm-Message-State: AOJu0YzpZE6spR3210SSGIKQhvOXjPm1evdMpuwT6d+oTQyNRCFMYyUF B19JeLhvwAE5pEiDmZTpBgI56zE9Y89EnwLjnFzeHIJJ4EwnLIl+rI3lidfus+AbuFW+Y9g8Oqt BIhNX2Skv4FPSoCtzEhQCjeAo+d8x/Uwx X-Google-Smtp-Source: AGHT+IE0ylqLIrgdeTxC2foVc0VAA2c26SDOCg8AZttp9ZLnL4/pUYhgJmrMsE+DyF75S2pXbFGyoWWUtrtnQGZ8+vc= X-Received: by 2002:a05:6870:698d:b0:261:360:746c with SMTP id 586e51a60fabf-28710a8d214mr4839092fac.19.1727559449835; Sat, 28 Sep 2024 14:37:29 -0700 (PDT) MIME-Version: 1.0 From: yudhi s Date: Sun, 29 Sep 2024 03:07:17 +0530 Message-ID: Subject: Context variable in application and trigger code To: pgsql-general Content-Type: multipart/alternative; boundary="00000000000056006c062334c7bd" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000056006c062334c7bd Content-Type: text/plain; charset="UTF-8" Hi, We have a trigger function called from a trigger which executes before inserting rows in the table (say TAB1). This trigger function does some conversion of code to description and persists the description in the table in respective columns. We want to keep this trigger as light as possible as there will be 100's million rows inserted into this table from multiple input sources and the conversion should only happen the inserts which happen from a specific input data stream. There are 4-5 different input sources which will ingest data into this table (some are using file based processing framework and some are using other streaming technology). Say for example we want this description to only be fetched for input source - 1, but not others. We don't have any such column persisted in the table which can be checked for the input data stream such as this code to describe decoding can be made conditional. Are there any techniques possible in which we can set some parameter or session context variable in application code level to determine the input data source, which can then be checked within the trigger function code at the very first and thus will avoid querying the "CODE" table every time the trigger executes? *Existing sample trigger code:-* CREATE OR REPLACE FUNCTION code_to_desc( ) RETURNS trigger LANGUAGE plpgsql AS $function$ declare code_description code.code%TYPE; begin select currency_description_text into code_description from code where code = new.code_input; IF FOUND THEN NEW.code_input := code_description; END IF; return NEW; end; $function$; Regards Yudhi --00000000000056006c062334c7bd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,
We have a trigger function called from a trigger w= hich executes before inserting rows in the table (say TAB1). This trigger f= unction does some conversion of code to description and persists the descri= ption in the table in respective columns. We want to keep this trigger as l= ight as possible as there=C2=A0will be 100's million rows inserted into= this table from multiple input=C2=A0sources and the conversion should only= happen=C2=A0 the inserts which happen from a specific input data stream. <= br>
There are 4-5 different input sources which will ingest data into th= is table (some are using file based processing framework and some are using= other streaming technology). Say for example we want this description to o= nly be fetched for input source - 1, but not others.=C2=A0 We don't have any such column persisted in the table which can be check= ed for the input data stream such as this code to describe decoding can be = made conditional.=C2=A0=C2=A0

Are there any techni= ques possible in which we can set some parameter or session context variabl= e in application code level to determine the input data source, which can t= hen be checked within the trigger function code at the very first and thus = will avoid querying the "CODE" table every time the trigger execu= tes?


Existing sample trigger cod= e:-

CREATE OR REPLACE FUNCTION code_to_desc( )
RETURNS trigge= r
LANGUAGE plpgsql
AS $function$
declare code_description code.cod= e%TYPE;
=C2=A0begin
=C2=A0 =C2=A0 =C2=A0select currency_description_t= ext into code_description
=C2=A0 =C2=A0 =C2=A0from code
=C2=A0 =C2=A0= where code =3D new.code_input;

=C2=A0 IF FOUND THEN NEW.code_input :=3D code_description;=C2=A0
=C2=A0 END IF;=C2=A0=C2=A0

=C2=A0 =C2=A0 = return NEW;
=C2=A0end;
$function$;

Regards
Yudhi
--00000000000056006c062334c7bd--