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 1sopk6-00E8zk-Dj for pgsql-general@arkaria.postgresql.org; Thu, 12 Sep 2024 19:44:39 +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 1sopk6-00Fsj3-0f for pgsql-general@arkaria.postgresql.org; Thu, 12 Sep 2024 19:44:38 +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.94.2) (envelope-from ) id 1sopk5-00Fsia-L5 for pgsql-general@lists.postgresql.org; Thu, 12 Sep 2024 19:44:37 +0000 Received: from mail-il1-x136.google.com ([2607:f8b0:4864:20::136]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sopk2-000qkz-Dv for pgsql-general@postgresql.org; Thu, 12 Sep 2024 19:44:36 +0000 Received: by mail-il1-x136.google.com with SMTP id e9e14a558f8ab-3a07bd770e2so6655685ab.0 for ; Thu, 12 Sep 2024 12:44:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1726170274; x=1726775074; darn=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=Wio89z3c7Pt6rvYJ2f2TWoYFdtqsO26BYgIZx/PCp8I=; b=BpBnri3g7Czox9teUCOPa3Dpc7nJUrHGYqT46+ibq9ICikh6vP+gJPQBdCI1HBg87x UDKR35EY3LIkUCT339LFVxacwcB09nhdh+On3TVPMW6rZEvBdBPGl3ioGctoQG3xGmPZ a/rWkT+Fed8R/Dmw4Wfz/gtSeJtrYtQI0JwySlZr9OpzmxWInpMAXMhuQisreRDz/x+A FdGFdW6fnrFUulNvk6twQCHv27bIE5hUEl+4Z8S+gIc10Edb6kT0ae4V1+Krdr/GBagP iChP2TYku7fwINWoaGTbuCxz7i56JzQm5gTVRzikQFOTUsZnw1UcwuwXGuJeG5joUPSJ HlxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726170274; x=1726775074; 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=Wio89z3c7Pt6rvYJ2f2TWoYFdtqsO26BYgIZx/PCp8I=; b=vz2rfq38LrIJCDg5Vt+JRhEGLGmV5IYHiohuJwG/0w3FxYXtdSymlsVklIyMhYLaAL FqcXQVpxEqlBLV7pLg9AjDrjg2EOrZVNJWxOrcy/+UmIu2pRX5cZcWxRnJwGk4dfAkKp KGR1+uas2daSKUHNaVAXpEyQKlh3dUL/DO5cFugqUo8j1q1bjdCBiJYArgehGookO2g7 DYSDsMEXzwqxFbTv6XSnbkLYRPpWE86MoBLuyifwIs3+ThIM/JbFpZGWwYRoUd+mJ17F h7fado2g4Du2ZS5xVOrANDEP7onFXKdVaOueDEdnfsumpDqaxNKz9986eTSLLchAgtAd 2gPg== X-Gm-Message-State: AOJu0YzK7GTJQx2EkRYh/b1300wtAfq8GhyvfgTZyKzqDySbSbxT/vxK WHQFwApvwvBVhSiaMGmLiq/LaejRTnC26Xmbs8QVXfs8n+w/Cl0w8UpzIxCfEffIowyFRYI+WPy 4yTf3mAqOVk3gCvaD6l9AypesHCc= X-Google-Smtp-Source: AGHT+IG2d5/iLJIW1xelA4pBZyQ1ahBlX2iH40zDt78DCkg+PafRTXhanvDUHKhivHmRK3dXyO6PF12Nh+uX69tkth4= X-Received: by 2002:a05:6e02:144e:b0:398:4bda:cf66 with SMTP id e9e14a558f8ab-3a084942bdfmr47889275ab.18.1726170273609; Thu, 12 Sep 2024 12:44:33 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Florents Tselai Date: Thu, 12 Sep 2024 22:43:56 +0300 Message-ID: Subject: Re: Better way to process records in bash? To: Ron Johnson Cc: pgsql-general Content-Type: multipart/alternative; boundary="000000000000faffd00621f15518" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000faffd00621f15518 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Sep 12, 2024 at 6:08=E2=80=AFPM Ron Johnson wrote: > (This might be a bash question instead of a PG question, or it might be a= n > A/B question.) > > I need to process table records in a bash script. Currently, I read them > using a while loop and redirection. The table isn't that big (30ish > thousand rows), and performance is adequate, but am always looking for > "better". > > Here's the current code: > declare f1 f3 f8 > while IFS=3D'|' read f1 f3 f8; do > something f8 f3 f1 > done < <(psql -XAt -c "select f1, f3, f8 from some.table_name;") > > -- > Death to America, and butter sauce. > Iraq lobster! > Another approach I've found more enjoyable in some cases, is using select to_jsonb(...) on the resultset, and then pipe this to jq . This will preserve (more than) decent performance, something you'll have to give up should you move to python for example. You'll still have to use bash at some point, but jq will be more expressive before that happens. So instead of psql -> bash, you'll have to psql --> jq --> (bash). --000000000000faffd00621f15518 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=




On Thu, Sep 12, 2024= at 6:08=E2=80=AFPM Ron Johnson <ronljohnsonjr@gmail.com> wrote:
(This might be a bash question instead of a PG question, or it m= ight be an A/B question.)

I need to process table record= s in a bash script.=C2=A0 Currently, I read them using a while loop and red= irection.=C2=A0 The table isn't that big (30ish thousand rows), and per= formance is adequate, but am always looking for "better".

Here's the current code:
declare f1 f3 f8
while IFS=3D'|' read f1 f3 f8; do
=C2= =A0 =C2=A0 something f8 f3 f1
done < <(psql -XAt -c "select f= 1, f3, f8 from some.table_name;")

--
Death to America, and butter sauce= .
Iraq lobster!

Another approach I've found more enjoyable in some cases,
<= div>is using select to_jsonb(...) on the resultset, and then pipe this to <= a href=3D"https://jqlang.github.io/jq/">jq.
This will preserv= e (more than) decent performance,
something you'll have to gi= ve up should you move to python for example.

You&#= 39;ll still have to use bash at some point,
but jq will be more e= xpressive before that happens.
So instead of psql -> bash, you= 'll have to psql --> jq --> (bash).

--000000000000faffd00621f15518--