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 1tIGWB-00DJ0k-J8 for pgsql-novice@arkaria.postgresql.org; Tue, 03 Dec 2024 00:11:55 +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 1tIGW8-0056u6-QU for pgsql-novice@arkaria.postgresql.org; Tue, 03 Dec 2024 00:11:54 +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 1tIGW8-0056ty-Cu for pgsql-novice@lists.postgresql.org; Tue, 03 Dec 2024 00:11:53 +0000 Received: from mail-oa1-x31.google.com ([2001:4860:4864:20::31]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1tIGW6-000jfc-MZ for pgsql-novice@lists.postgresql.org; Tue, 03 Dec 2024 00:11:52 +0000 Received: by mail-oa1-x31.google.com with SMTP id 586e51a60fabf-29666708da7so3069202fac.0 for ; Mon, 02 Dec 2024 16:11:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1733184710; x=1733789510; darn=lists.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=W5g18kmHHdDlNQ2njkJ0231QwtYqUtw8GKwmvYqgzjo=; b=P/YrIP8Mq5eeznbHVC4OyTJUMsC5Uj6mWeqvQlZ01nbWgV2EXEF5EbTK+wk76QJHuj lflIScTdoQZNwyrRs/d6ov+cqxIXtyECb22H30O4jgK9orTrxsqAq53uo04MeHk/4LpV 6BTtmX+4C1k0CFyHxh8+KTNNF6OPWTpa2g2W3w2ASwaHjU3CTezENPxCo/fhShbTamcC tPFxRzvhWttqOdH6zsNRrCaWtOptg8VxKplsmAVgBDAsWtXrDd7sL/EKYUcEXE9ithaB 6XRnkTkqgEq3gs8LRRco1sIWOQf/r2FzIrZ1BiE/Xn0wbnTe0MykwUhQnV0m8CK0m9lJ m76g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733184710; x=1733789510; 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=W5g18kmHHdDlNQ2njkJ0231QwtYqUtw8GKwmvYqgzjo=; b=WD2cdE8XsWCzOBi+tFngY3M6uvzqRWSxktOUTNbhbZKF1hP0a4/ZRZT5SU/e5I6Tgh s41kJB89HGk1okQ/TDuP61/IK4WbaSIFf4Dey3mzk0WO0h6nmhd6EXdqNjHp232rbOLm JKPH89mhhWL3dTw3lVOG22c4Tz6T4OfjqRwOrYvf0ZGZC29HGz6JP0hz7NYNTrcHAgr8 fNsUOXLAIO2sVK6anMpHTB04+RULTYxDN0FY8tKz/MRpqg0J17T21piAfST/zJzTfyKZ qhyVkhAVHPyTJ+MOgBqNGNCWQ+m2CWTrlp1PPDIkV36Lk0BDCr4IF/S8ea/1Tq8lfCLI aUJA== X-Forwarded-Encrypted: i=1; AJvYcCWn1VK31Hbb37KlceevFFC4GOp/gv0oZw8XrlbijwR32TYgeV8BGPTG7ZrWeXx7Wub0wWi6BNpy1nhuwY4=@lists.postgresql.org X-Gm-Message-State: AOJu0YxO+GOrHX5FABXlOo3TOySC7vqwuvo+ekFLCgVJPZqx7eA6JRMo SI/xhuq80ONxDJzBKopecRGfzT0grnTXv8XZm5IKxmgcLnsz2bVsyPwr786g+0SdhpKXBDjNXaS Gme/vkqJUkglxwtGseVbaCzXkS+cefMnEUvw= X-Gm-Gg: ASbGncveDlgmEE9Svrd0EPAw0cV642g35I8DKfbNgqutrVihXEXCzgZLIzdSBI+9A1v LAhsg4Jc816+TVtu25I3XvlzdsVwDmPs= X-Google-Smtp-Source: AGHT+IEXjtnBF8IB8i/khkkU/sr1vf3WuVrQNHHViu1kJGfH7CPQQXAAcovAjIdvtWj18xzU2cAucf95E/B4puqDAfA= X-Received: by 2002:a05:6870:d620:b0:29e:3d0b:831 with SMTP id 586e51a60fabf-29e888b738dmr294123fac.40.1733184709681; Mon, 02 Dec 2024 16:11:49 -0800 (PST) MIME-Version: 1.0 References: <487DB217-EA37-4139-AB97-B61B04ECAEA7.1@smtp-inbound1.duck.com> <493C622D-D3B6-4662-A617-EBCCDE5AA4DF.1@smtp-inbound1.duck.com> <30948e6771500c0e9d8b587f4e34165aadb1cc0b.camel@cybertec.at> <4FB93541-3986-4C8F-9571-1FBD8655A686.1@smtp-inbound1.duck.com> In-Reply-To: <4FB93541-3986-4C8F-9571-1FBD8655A686.1@smtp-inbound1.duck.com> From: "David G. Johnston" Date: Mon, 2 Dec 2024 17:11:13 -0700 Message-ID: Subject: Re: Command Line option misunderstanding To: punch-hassle-guise@duck.com Cc: Laurenz Albe , "pgsql-novice@lists.postgresql.org" Content-Type: multipart/alternative; boundary="000000000000f369e40628528238" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000f369e40628528238 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Dec 2, 2024 at 4:50=E2=80=AFPM wrote: > The problem seems to be, as alluded to by others attempting to help me > > that the problem only exists when using -c on the same line as -v. > The word "line" here belies further misunderstanding of how shell-executed commands work (the following "two line" command is still just one actual multiple-option command invocation). psql -v a=3D1 \ -c 'select :a' It is best to just say "using -c and -v together". It is correct that we haven't pointed out, probably because for experienced people it seems obvious, that using -v and -c (or putting \set in -c) is a pointless thing to do. But psql doesn't go about trying to analyze intent here so, yes, you either get useless successful output in response or a confused server. That said... psql -v a=3D1 -c '\echo :a' postgres 1 So it truly is just this specific SQL-related usage that is pointless, not combining -v and -c generally (I'm sure a useful backslash command can be substituted for \echo) > > Related Question: > > Documentation says: > > *command* must be either a command string that is completely parsable by > the server (i.e., it contains no psql-specific features), or a single > backslash command. > > $psql -h anna -d GT7 -c "\set a '11117' \\ select evt_id from events > where sport_mode_evt_id=3D:a" > Really not caring that you are turning on autocommit... Anyway, what I believe you managed to accomplish here is to set the named variable "a" to the value Then proceeded to do nothing with that variable since the -c command was done being evaluated in the "single backslash command" mode. David J. --000000000000f369e40628528238 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Dec 2, 2024 at 4:50=E2=80=AFPM <punch-hassle-guise@duck.com> wrote:<= /span>
=20 =20

The problem seems to be, as alluded to by others attempting to help me

that the problem only exists when using -c on the same line as -v.

The word "line" here belies fu= rther misunderstanding of how shell-executed commands work (the following &= quot;two line" command is still just one actual multiple-option comman= d invocation).
psql -v a=3D1 \
-c 'select :a'
=

It is best to just say "using -c and -v together"= .

It is correct that we haven't pointed out, proba= bly because for experienced people it seems obvious, that using -v and -c (= or putting \set in -c) is a pointless thing to do.=C2=A0 But psql doesn'= ;t go about trying to analyze intent here so, yes, you either get useless s= uccessful output in response or a confused server.

Tha= t said...
psql -v a=3D1 -c '\echo :a' postgres
1

So it truly is just this specific SQL-related usage that = is pointless, not combining -v and -c generally (I'm sure a useful back= slash command can be substituted for \echo)


Related Question:

Documentation says:

command must be either a command string that is completely parsable by the server (i.e., it contains no psql-specific features), or a single backslash command.

$psql -h anna -d GT7=C2=A0=C2=A0 -c "\set=C2=A0 a '11117= 9; \\ select evt_id from events where sport_mode_evt_id=3D:a"

Re= ally not caring that you are turning on autocommit...

= Anyway, what I believe you managed to accomplish here is to set the named v= ariable "a" to the value <single-quote 11117 single-quote blah= -blah-blah equals colon a>

Then proceeded to do not= hing with that variable since the -c command was done being evaluated in th= e "single backslash command" mode.

David J= .

--000000000000f369e40628528238--