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 1qOJ9q-007RFl-Et for pgsql-sql@arkaria.postgresql.org; Tue, 25 Jul 2023 14:37: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 1qOJ9o-00Go0B-Uf for pgsql-sql@arkaria.postgresql.org; Tue, 25 Jul 2023 14:37:00 +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 1qOJ9o-00Go03-Ke for pgsql-sql@lists.postgresql.org; Tue, 25 Jul 2023 14:37:00 +0000 Received: from mail-oi1-x229.google.com ([2607:f8b0:4864:20::229]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1qOJ9l-000HKe-LN for pgsql-sql@postgresql.org; Tue, 25 Jul 2023 14:37:00 +0000 Received: by mail-oi1-x229.google.com with SMTP id 5614622812f47-3a4875e65a3so3533999b6e.2 for ; Tue, 25 Jul 2023 07:36:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1690295816; x=1690900616; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=XTGe4Rn0U3SFksD5GYpqCRljlQuxp8f/rrrokyk5DUg=; b=G08tTbw5u2RRJqoMqXDpA5sESTUiGZt+Hbmh2UNX6eAGk5Cyz7xjvtO48mX1+IgThG pTW6Ufkjz0hAtZr3Y4F9826VcOo3Wd3XXRqBKjSppwmmv9zC1q38NcrjVfDSUfT39bdM PCYiYLZn2ZP8d0fTuzPvKce/90lmBbrsj2xRTzLtwPMm57GMa7M1BKv9ruthi4rAayO5 5ufYunyv9Hykzjn6ch3u6pmdZ7e7tK8kQQQUW8WEaS1tJGjKeYNOtgsm+fTVZXzn2R5w NPKRBsXk8TihbcwrVPcBG5T6ZlW2RZKLUNxODugEFG6VzISm5oGfQ6PhLG7P3/sSh/ny vVRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690295816; x=1690900616; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=XTGe4Rn0U3SFksD5GYpqCRljlQuxp8f/rrrokyk5DUg=; b=dQj/SmZ2k7RvQs4eodei3Ctf3XefH+oZ/Bwfm+IGELOsv42mYHK8ZpkvivocwpKpNB JqPgRUglYyMN8i/XFaPAcz4g0SGG0FSIRNKshyvHecm096uosh0GxCyTlnc6/+NjDGe3 1cDSGiSlhqCw00HA7RfF2NqdynDghde5jS+HAS8H8kGfXPLXDp8RdW/QzbYDLPoxPbek Rg/Sdw01NHIqolDLu1lzndZdCyJztTJoGZjn42VPsRVMGWzxOVaC/z479Eg6sDWSde5H xt73g90EZzudOkvvJmJsmidZmBHaMKM4Hx0VWFAxbjvUOnp61R09MEeUGGcfnxpt+kPG UkgA== X-Gm-Message-State: ABy/qLYnoU/lGoj3m1xSS9Jo2lnHKcIq5XmDUO07fRLCgoShJ69QWzAb 9Y98ESBYYJR6yaNmHNq03izokN9vXxcof9ZSmpSHIE4f63g= X-Google-Smtp-Source: APBJJlF+Yq0fRSuulpKEmFq9y+tEcJABHePF+6+zDOc+6HucJ9l48aZOhbPBrqPpSznRdF7HPEyFGLD/VQY4ENgBHhQ= X-Received: by 2002:a05:6808:1506:b0:3a3:7ee9:8f17 with SMTP id u6-20020a056808150600b003a37ee98f17mr16015141oiw.39.1690295815694; Tue, 25 Jul 2023 07:36:55 -0700 (PDT) MIME-Version: 1.0 From: JORGE MALDONADO Date: Tue, 25 Jul 2023 09:35:45 -0500 Message-ID: Subject: Declaring a constant or variable in a query To: pgsql-sql@postgresql.org Content-Type: multipart/alternative; boundary="000000000000a8ed4f060150a919" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000a8ed4f060150a919 Content-Type: text/plain; charset="UTF-8" Hi, I am using *DataGrip *(a tool very much like pgAdmin) to run a query with several *UNION* clauses as follows: *SELECT fld1 as alias1, fld2 as alias2, fld3** as alias3**, fld4** as alias4**, fld5** as alias5** FROM table1 WHERE condition1* *UNION* *SELECT fld1 as alias1, fld2 as alias2, fld3** as alias3**, fld4** as alias4**, fld5** as alias5** FROM table2 WHERE condition2* *UNION* *SELECT fld1 as alias1, fld2 as alias2, fld3** as alias3**, fld4** as alias4**, fld5** as alias5** FROM table3 WHERE condition3* *UNION* *SELECT fld1 as alias1, fld2 as alias2, fld3** as alias3**, fld4** as alias4**, fld5** as alias5** FROM table4 WHERE condition4* I need *fld5* to always be a constant in every SELECT that I would like to read interactively or to set somewhere in the query (as a variable or constant for example). I tried to use a parameter for such field like this: *SELECT fld1 as alias1, fld2 as alias2, fld3** as alias3**, fld4** as alias4**, :fld5** as alias5** FROM table1 WHERE condition1* *UNION* *SELECT fld1 as alias1, fld2 as alias2, fld3** as alias3**, fld4** as alias4**, :fld5** as alias5** FROM table2 WHERE condition2* *UNION* *SELECT fld1 as alias1, fld2 as alias2, fld3** as alias3**, fld4** as alias4**, :fld5** as alias5** FROM table3 WHERE condition3* *UNION* *SELECT fld1 as alias1, fld2 as alias2, fld3** as alias3**, fld4** as alias4**, :fld5** as alias5** FROM table4 WHERE condition4* My issue using this approach is that *DataGrip *interactively asks for the input value 4 times, which means that the parameter value is asked the number of times it is specified no matter if the parameter name is exactly the same. In this example, the query has 3 *UNION *clauses that involve 4 *SELECT *statements, however, there can be more. I have read that it is possible to use a *DECLARE* statement but it seems to me that this solution forces me to use a *FUNCTION* and I would like to avoid it. Another solution that I saw is to declare a session level variable using *SET* and then use such variable in the query. I will very much appreciate your feedback on what would be my best choice. I am open to hearing new approaches. Respectfully, Jorge Maldonado --000000000000a8ed4f060150a919 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I am using DataGrip (a tool very much like pgAdmin)=C2=A0to= run a query with several UNION clauses as follows:

SELECT fld1 as alias1, fld2 as alias2, fld3=C2=A0as alia= s3, fld4=C2=A0as alias4, fld5=C2=A0as alias5=C2=A0FROM table1 WHERE condition1
UNION
SELECT fld1 as alias1, fld2 as alias2, fld3=C2=A0as alias3, fld4=C2=A0as alias4, fld5=C2=A0as alias5=C2= =A0FROM table2 WHERE condition2
UNION<= /div>
SELECT fld1 as alias1, fld2 as alias2, fld3=C2=A0as ali= as3, fld4=C2=A0as alias4, fld5=C2=A0as alias5=C2=A0FROM table3 WHERE condition3
UN= ION
SELECT fld1 as alias1, fld2 as alias2, fld3=C2= =A0as alias3, fld4=C2=A0as alias4, fld5=C2=A0as= alias5=C2=A0FROM table4 WHERE condition4
<= br>
I need fld5=C2=A0to always be a constant i= n every SELECT that I would like to read interactively or to set somewhere = in the query (as a variable or constant for example). I tried to use a para= meter for such field like this:

SELECT fld= 1 as alias1, fld2 as alias2, fld3=C2=A0as alias3, fld4= =C2=A0as alias4, :fld5=C2=A0as alias5=C2=A0FROM table1= WHERE condition1
UNION
SELECT fld1 as al= ias1, fld2 as alias2, fld3=C2=A0as alias3, fld4=C2=A0a= s alias4, :fld5=C2=A0as alias5=C2=A0FROM table2 WHERE = condition2
UNION
SELECT f= ld1 as alias1, fld2 as alias2, fld3=C2=A0as alias3, fld4<= b>=C2=A0as alias4, :fld5=C2=A0as alias5=C2=A0FROM tabl= e3 WHERE condition3
UNION
SELECT fld1 as alias1, fld2 as alias2, fld3=C2=A0as alias3, = fld4=C2=A0as alias4, :fld5=C2=A0as alias5=C2=A0= FROM table4 WHERE condition4

My issue using this approach is that DataGrip interactively=C2=A0asks for the input value 4 times, which means that the = parameter value is asked the number of times it is specified no matter=C2= =A0if the parameter name is exactly the same. In this example, the query ha= s 3 UNION clauses that involve 4 SELECT statements, however, = there can be more.

I have read that it is possible= to use a DECLARE statement but it seems to me that this solution=C2= =A0forces me to use a FUNCTION and I would like to avoid it. Another= solution that I saw is to declare a session level variable using SET=C2=A0and then use such variable in the query.

I = will very much appreciate your feedback on what would be my best choice. I = am open to hearing new approaches.

Respectfully,
Jorge Maldonado

=
--000000000000a8ed4f060150a919--