Postgres: force generic plan for better nullability inference.

[joeydewaal]

Currently when using the query! and query_as! macro's sqlx uses explain (verbose, format json) execute {statement_id} to get the query plan of a prepared statement/query. Then looks through the plans and tries to be more accurate with the type inference.

If a prepared statement has query parameters it needs to fill then in with a valid argument and uses NULL for every one because it is always a valid argument.

This causes the query planner to give a query plan back that is optimized when the function arguments are all NULL, this is not always correct.

This pr forces postgres to use a generic execution plan when describing a prepared statement with function arguments. That way it won't make optimizations based on the given parameters.

Fixes #3539, #1265, #2796 (comment), #3408, #2127

[abonander]

I think providing a constant value may end up with the same problem in different queries.

I'm wondering if at a certain point, it would be easier to parse the SQL, just to get an idea of its structure. We'd still want to use the database for type analysis though.

[joeydewaal]

I think providing a constant value may end up with the same problem in different queries.

I'm wondering if at a certain point, it would be easier to parse the SQL, just to get an idea of its structure. We'd still want to use the database for type analysis though.

I just found out about force_generic_plan which gets the same result without providing a random value for a type.

[abonander]

That sounds like it has potential, yeah. Reducing the planning overhead might help with compile times a bit too.

Make sure to do SET LOCAL so it doesn't persist for the lifetime of the connection (you'll need to do it in a transaction). describe() can be called at runtime too.

[abonander]

Technically breaking since it can change the output of analysis.

Also kind of why I'm starting to think maybe we should parse the SQL. The output of EXPLAIN isn't meant to be stable at all.

[joeydewaal]

I think that's going to make the macro's quite a bit slower though

[abonander]

It'd be on-par with parsing the EXPLAIN output, and one less round-trip to the server (which is going to be where most of the overhead is anyway).