Обсуждение: Figure out nullability of query parameters
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
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
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 <giacomo.cavalieri@icloud.com> 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.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
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 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?
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’t 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’ve shown here is part of that. Not sure we’d turn it down but someone will need to step up and scratch their own itch in all likelihood (the request for similar functionality in the result comes up too).
David J.
It would be really handy to know that `$1` is being used as a non nullable value
To push back in a different way, how exactly would this be useful?
The system catalogs are the best place to get all the various information about a relation, including any and all constraints. Data type info via protocol, yes, but constraints seems a whole other level of bother.
Cheers,
Greg
--
Crunchy Data - https://www.crunchydata.com
Enterprise Postgres Software Products & Tech Support