MIME-Version: 1.0
In-Reply-To: <4915B05B-90B6-4CC2-86E7-EF7C1E2E38C9@icloud.com>
References: <4915B05B-90B6-4CC2-86E7-EF7C1E2E38C9@icloud.com>
From: "David G. Johnston" <david.g.johnston@gmail.com>
Date: Fri, 27 Jun 2025 07:52:56 -0700
Message-ID: <CAKFQuwaBXfo1LaUWYkPtZaTOaeua6b2SDmX=PtB0r9cvcNYd+w@mail.gmail.com>
Subject: Re: Figure out nullability of query parameters
To: Giacomo Cavalieri <giacomo.cavalieri@icloud.com>
Cc: "pgsql-general@lists.postgresql.org" <pgsql-general@lists.postgresql.org>
Content-Type: multipart/alternative; boundary="0000000000006eb77106388ed588"
Archived-At: <https://www.postgresql.org/message-id/CAKFQuwaBXfo1LaUWYkPtZaTOaeua6b2SDmX%3DPtB0r9cvcNYd%2Bw%40mail.gmail.com>
Precedence: bulk

--0000000000006eb77106388ed588
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Friday, June 27, 2025, Giacomo Cavalieri <giacomo.cavalieri@icloud.com>
wrote:

>
> 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?
>

There is no attempt in the system to try and pass constraint information
through the query planner and expose it to the client.  It doesn=E2=80=99t =
seem
like there is sufficient utility to try and do so.  The fact that it pretty
much only works in the exact query form you=E2=80=99ve shown here is part o=
f that.
Not sure we=E2=80=99d turn it down but someone will need to step up and scr=
atch
their own itch in all likelihood (the request for similar functionality in
the result comes up too).

David J.

--0000000000006eb77106388ed588
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Friday, June 27, 2025, Giacomo Cavalieri &lt;<a href=3D"mailto:giacomo.c=
avalieri@icloud.com">giacomo.cavalieri@icloud.com</a>&gt; wrote:<br><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div style=3D"line-break:after-white-space"><br><di=
v>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 tod=
ay, or would there be a way to surface this kind of information for query p=
arameters in the extended protocol?</div></div></blockquote><div><br></div>=
<div>There is no attempt in the system to try and pass constraint informati=
on through the query planner and expose it to the client.=C2=A0 It doesn=E2=
=80=99t seem like there is sufficient utility to try and do so.=C2=A0 The f=
act that it pretty much only works in the exact query form you=E2=80=99ve s=
hown here is part of that.=C2=A0 Not sure we=E2=80=99d turn it down but som=
eone will need to step up and scratch their own itch in all likelihood (the=
 request for similar functionality in the result comes up too).</div><div><=
br></div><div>David J.</div><div><br></div>

--0000000000006eb77106388ed588--