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 1uVAKO-00Ecm8-Bh for pgsql-general@arkaria.postgresql.org; Fri, 27 Jun 2025 14:45:20 +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 1uVAKM-002SrO-2p for pgsql-general@arkaria.postgresql.org; Fri, 27 Jun 2025 14:45:18 +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 1uVAKL-002Sr4-O1 for pgsql-general@lists.postgresql.org; Fri, 27 Jun 2025 14:45:18 +0000 Received: from mail-ej1-x631.google.com ([2a00:1450:4864:20::631]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1uVAKK-004Hty-1z for pgsql-general@lists.postgresql.org; Fri, 27 Jun 2025 14:45:17 +0000 Received: by mail-ej1-x631.google.com with SMTP id a640c23a62f3a-ad574992fcaso391212266b.1 for ; Fri, 27 Jun 2025 07:45:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1751035514; x=1751640314; 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=MNhVfNW89+c8BIo4bUAFbrIlkVkyc4ZVGj60hzmBHtk=; b=ZZaUpDw5uF+IF4RlMxFg6LVzX6A4j7Ig4IKoiMPpuGBDjAnrBgtgAeaWfV9fBLGRXH ntdUaSMPzlUdd2yxwBJI6e3K94bpN1RSuY9encSx4pZCq3PqPWPViFNAzdvoLFul0+Wu THhHSl5PbxOUzVXDE3cOWhkXoYs4lBr1RYVbSrM4WQoXXr2h/gfgn0jikVq0+Ry315O0 QSw+9DTahYUTce4qI9fdaORWY7oHEq7BsAW7RUGuytHtXTAUJ2xPypY3jMKQO8f1Dy8h 6DgrQtI2kxaamIbjySIkjzKtLJ2xi48oOgv2r/eSNxMnyOjnansmxo01PK4aWg1ujTWT HOIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1751035514; x=1751640314; 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=MNhVfNW89+c8BIo4bUAFbrIlkVkyc4ZVGj60hzmBHtk=; b=fRn3xpOUDsitayyFZN/vF0Bj9x5VHChA7Z+PTIq1lpSS4cDCkeTufQoX2fLHeJErOI HT6m/hE6u4OxtYpZit70oZkoZZTycwGBiFF+3ox25mV+Vpe/jJ/Dehv/owFHUGut/EPL frNeNM3225xpXDeuKpNAqtZgC+2/zYrmDOU3rdywuEnT8klCqRn02wgwIBlUYO11B1yN SJdBDuQQpoMSdKGdML+wwASeANtimgS2Uxv73LNHh+xuPVDokcs3rXN5S0JCP66eDgZR Lpyz1GCwF0rFGtvtX57k/E2KfYtrUWMfaRsToP1m1vGJUPwWrRWy2TjfgUxrTtQVMCd9 NLQA== X-Gm-Message-State: AOJu0YzOK1vJV7elpGDbw2KQS0At71sxVobKqHjDuMP7gm+HpsTkyEZZ xMVgOjn/QEmIHgi9YPNS9xu6ewHiSRdlIiR+UzHbqoOpR7Bxw24hOnrcvtK5XNGQunhc5PaU+NJ 89tjV9Q1gbr3X4u3r+u2MxTkItUfvn3o= X-Gm-Gg: ASbGncv0//ryEGfu86EvhC1CuSWemBMoO4MBcwAbFdZdqBeh4reEnLYbkg0c5TGUUCN KOMFzfDTBwc8vTClRf5YkF4v1mJv1N5LKm83xZMsHJd/252eGpflbuoNVh5/2/OLUFhRHFeMKNV fz0Kk1mVO3mV++tDiTeNgmQKouu7Xysa/1QwF/IXug5/3O9+VxbZQN0nMWNGVfo63mbTgRbHToh 5DJfP0zkDzg8lF1 X-Google-Smtp-Source: AGHT+IHf3VqI7+N3mHRgqBOMo1iU9HISvZ+6bAcg9Xp/LVd1GFo7VBA0mxJ3fuzRJYeSxi/c9OdfUOqMlGr4ucQe58E= X-Received: by 2002:a17:907:2d90:b0:ae0:1883:78ce with SMTP id a640c23a62f3a-ae35011f48fmr321150166b.47.1751035513552; Fri, 27 Jun 2025 07:45:13 -0700 (PDT) MIME-Version: 1.0 References: <4915B05B-90B6-4CC2-86E7-EF7C1E2E38C9@icloud.com> In-Reply-To: <4915B05B-90B6-4CC2-86E7-EF7C1E2E38C9@icloud.com> From: Petr Kada Date: Fri, 27 Jun 2025 16:45:02 +0200 X-Gm-Features: Ac12FXz9o3YPvviIvF9W-g_O5_DDaSlU2KwLvArexOh3e5pGYXMl03mXeWquw1o Message-ID: Subject: Re: Figure out nullability of query parameters To: Giacomo Cavalieri Cc: pgsql-general@lists.postgresql.org Content-Type: multipart/alternative; boundary="000000000000c6435706388eb941" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000c6435706388eb941 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, I have no idea how/if this is possible using the query protocol but I would try to parse the INSERT statement to get the table and columns names and then look up whether they are nullable in the information schema ( https://www.postgresql.org/docs/current/infoschema-columns.html) Petr On Fri, Jun 27, 2025 at 4:31=E2=80=AFPM Giacomo Cavalieri < giacomo.cavalieri@icloud.com> wrote: > Hello! > I=E2=80=99m Giacomo, I=E2=80=99m the maintainer of < > https://github.com/giacomocavalieri/squirrel>, a tool that can generate > type safe bindings to run and decode the results of Postgres queries. It > does that by implementing the extended query protocol, which, among other > things, returns the OIDs of the query parameters=E2=80=99 types. > This is really handy and has worked great so far but I=E2=80=99m running = into some > rough edges when it comes to the nullability of query parameters. > > Take a query like this one: > ``` > insert into some_table(not_null_col, nullable_column) > values ($1, $2) > ``` > It would be really handy to know that `$1` is being used as a non nullabl= e > value, while `$2` could actually be null. Can this already be achieve > today, or would there be a way to surface this kind of information for > query parameters in the extended protocol? > > Sorry if this is not the proper list, I=E2=80=99m very new to all of this= :) > Thanks! > > Giacomo > --000000000000c6435706388eb941 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0
I have no idea how/if this is possible using = the query protocol but I would try to parse the INSERT statement to get the= table and columns names and then look up whether they are nullable in the = information schema (https://www.postgresql.org/docs/current/infoschema-col= umns.html)

Petr

On Fri, Jun 27, 2025 at 4:3= 1=E2=80=AFPM Giacomo Cavalieri <giacomo.cavalieri@icloud.com> wrote:
Hello!
I=E2=80=99m Giacomo, I= =E2=80=99m the maintainer of <https://github.com/giacomocavalieri/squirr= el>,=C2=A0a tool that can generate type safe bindings to run and dec= ode the results of Postgres queries. It does that by implementing the exten= ded query protocol, which, among other things, returns the OIDs of the quer= y parameters=E2=80=99 types.
This is really handy and has worked = great so far but I=E2=80=99m running into some rough edges when it comes to= the nullability of query parameters.

Take a query= like this one:
```
insert into some_table(not_null_col= , nullable_column)
values ($1, $2)
```
It wou= ld be really handy to know that `$1` is being used as a non nullable value,= while `$2` could actually be null. Can this already be achieve today, or w= ould there be a way to surface this kind of information for query parameter= s in the extended protocol?

Sorry if this is not t= he proper list, I=E2=80=99m very new to all of this :)
Thanks!

Giacomo
--000000000000c6435706388eb941--