Subject: Figure out nullability of query parameters

From: Giacomo Cavalieri <[email-masked]>
Date: Fri, 27 Jun 2025 16:30:41 +0200

Hello!
I’m Giacomo, I’m 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’ types.
This is really handy and has worked great so far but I’m 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 nullable 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’m very new to all of this :)
Thanks!

Giacomo

---

From: Petr Kada <[email-masked]>
Date: Fri, 27 Jun 2025 16:45:02 +0200

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 PM Giacomo Cavalieri <
[email-masked]> wrote:

> Hello!
> I’m Giacomo, I’m 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’ types.
> This is really handy and has worked great so far but I’m running into some
> rough edges when it comes to the nullability of query parameters.
>
> It would 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 would there be a way to surface this kind of information for
> query parameters in the extended protocol?
>