Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1n59wf-0003hW-KL for pgsql-interfaces@arkaria.postgresql.org; Wed, 05 Jan 2022 17:19:29 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1n59we-0006yZ-3D for pgsql-interfaces@arkaria.postgresql.org; Wed, 05 Jan 2022 17:19:28 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1n59wd-0006yH-Oj for pgsql-interfaces@lists.postgresql.org; Wed, 05 Jan 2022 17:19:27 +0000 Received: from mail-qk1-x729.google.com ([2607:f8b0:4864:20::729]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1n59wb-0002Ub-2p for pgsql-interfaces@lists.postgresql.org; Wed, 05 Jan 2022 17:19:26 +0000 Received: by mail-qk1-x729.google.com with SMTP id r139so69188qke.9 for ; Wed, 05 Jan 2022 09:19:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HhLVcjJHaqAn+HMxO2PIoZnk4j3tPpULzNAxIlHcBCM=; b=TZKHi+YgpH2w7ifpJe0+VJLJwXvqzVdbSNKk02RF3BKqxnAdMBzZtLM+oKD3kpl9Kp waOhTxi9iKiMSXL8kcg6ppHPCGFz9BPf5VSdCfmVf9Dm2W1LnNHmzF6Zq/BKGcDv6yyE A4+RtR29WcAqw7vWpb8VI/3tifp9uAOBBj3NIaK3+PFc1KtSYQSTfcoewXHtiNmn6CAM MNDxxcPnATvDZ0ucw+f3B0c1kYFhzaG5FzIrTyNrid+BJV+CGiosW5zdpvPRnEKxzk7I TZHkqe9196VUnUw2NlyP/tHMmHd9QBOFFAg3ZPC7OQbzi4uwXTOYDkIsfVDGr3zORm/J PG0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HhLVcjJHaqAn+HMxO2PIoZnk4j3tPpULzNAxIlHcBCM=; b=zLJ2hjdh6k53Trlu6/DJ04MLz/ICyoW0jAwiueuPM2TQ+t2IvVpo1vBf+TjC08TDyt ZdJckY4IVzIJA5NZcgWLvfyUR4i4OEiyJ3IG2Wh6X5ZAPxugIBmmDhx9Bh1frJZ9NgZL EhpXMW9aAgqJJv3OXREa+n1HzrMQte+DQ3wVronooHTAAveBzKDHm9zoYZl2VFXox3ls Mci7w2SEdVkKeZ01BkVGWJrLRbZO/nN4MYxMUVyQ27J5tFRzLX+/V0R6Sqge9bDRn/Aw PULcYDc79u/l0wkep/hA7OtnMlm/gkcB104tMCYvbjjJ+k2uP6/G8X8GZdKw7eHMFiX5 rPhA== X-Gm-Message-State: AOAM53313nVEe8tJhWPVDY5UDvIeH5y4MQ7mR9387mfEUpVJDYZ8x9/G 2RewL5m5/ozvuhNVC05Yxb33SghHsfk7wSlctQo= X-Google-Smtp-Source: ABdhPJyGljvEpygHR4G0C3us95Eesg/7IDW3lk0MedGDPAiNFIiE3xc8QJgqO9L+NX3MaEUXkQ7frccbAXzttDhxMSU= X-Received: by 2002:a05:620a:bcb:: with SMTP id s11mr38832920qki.217.1641403163926; Wed, 05 Jan 2022 09:19:23 -0800 (PST) MIME-Version: 1.0 References: <303861.1641402467@sss.pgh.pa.us> In-Reply-To: <303861.1641402467@sss.pgh.pa.us> From: Les Date: Wed, 5 Jan 2022 18:19:12 +0100 Message-ID: Subject: Re: psycopg3 - parameters cannot be used for DDL commands? To: Tom Lane Cc: pgsql-interfaces@lists.postgresql.org Content-Type: multipart/alternative; boundary="00000000000084e6a905d4d8f4a0" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000084e6a905d4d8f4a0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ok, thanks! Tom Lane ezt =C3=ADrta (id=C5=91pont: 2022. jan. 5., Sz= e, 18:07): > Les writes: > > PostgreSQL server log: > > > 2022-01-05 17:35:25.831 CET [58] ERROR: syntax error at or near "$1" a= t > > character 35 > > 2022-01-05 17:35:25.831 CET [58] STATEMENT: ALTER USER postgres WITH > > PASSWORD $1 > > Yeah, as a general rule parameters can only be used in DML commands > (SELECT/INSERT/UPDATE/DELETE). Utility commands don't support them > because they don't have expression-evaluation capability. > > (Perhaps this will change someday, but don't hold your breath.) > > > Passwords can also contain special characters. If I can't use parameter= s > to > > do this, then how should I quote them in a safe way? > > Most client libraries should have a function to convert an arbitrary > string into a safely-quoted SQL literal that you can embed into the > command. I don't know psycopg3, so I don't know what it has for that. > > regards, tom lane > --00000000000084e6a905d4d8f4a0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ok, thanks!

Tom Lane <tgl@sss.pgh.pa.us> ezt =C3=ADrta (id=C5=91pont: 2022. jan. 5= ., Sze, 18:07):
= Les <nagylzs@gmai= l.com> writes:
> PostgreSQL server log:

> 2022-01-05 17:35:25.831 CET [58] ERROR:=C2=A0 syntax error at or near = "$1" at
> character 35
> 2022-01-05 17:35:25.831 CET [58] STATEMENT:=C2=A0 ALTER USER postgres = WITH
> PASSWORD $1

Yeah, as a general rule parameters can only be used in DML commands
(SELECT/INSERT/UPDATE/DELETE).=C2=A0 Utility commands don't support the= m
because they don't have expression-evaluation capability.

(Perhaps this will change someday, but don't hold your breath.)

> Passwords can also contain special characters. If I can't use para= meters to
> do this, then how should I quote them in a safe way?

Most client libraries should have a function to convert an arbitrary
string into a safely-quoted SQL literal that you can embed into the
command.=C2=A0 I don't know psycopg3, so I don't know what it has f= or that.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 regards, tom lane
--00000000000084e6a905d4d8f4a0--