Why do we need the extra ReusableDefaultValue type? Isn't this equally readable without losing any type safety?

data ReusableVariableInfo
  = ReusableVariableInfo 
  { _rviType :: RQL.PGColumnType,
  , _rviDefault :: Maybe PGScalarValue
  } deriving (Show, Eq)

Because Maybe is subject a sort of Boolean blindness. In the current situation, we don't clearly separate AnnInpVals originating from the query, and those originating from user-provided arguments. So we have to string the default values through our code, and this is error-prone, as this issue shows. The reason that we incorrectly cached these kinds of queries in the first place is that the provided value was simply <|>'d with the default value (in validateVariables), thus forgetting the default value. ResuableDefaultValue forces us to think explicitly about what to do with default vs user-provided values, at least in some places.

Put differently: suppose you get a Maybe PGScalarValue somewhere, what kind of value is this? Is this a user-provided argument? If so, has the default value been applied? If not, where would you get that from? ReusableDefaultValue goes one step towards clarifying the answers to these questions.

Right, I see what you mean. In that case wouldn't the standard pattern be a newtype wrapper on PGScalarValue like this?

newtype ReusableDefaultValue = ReusableDefaultValue PGScalarValue
data ReusableVariableInfo
  = ReusableVariableInfo 
  { _rviType :: RQL.PGColumnType,
  , _rviDefault :: Maybe ReusableDefaultValue
  } deriving (Show, Eq)

i.e, why parameterize ReusableDefaultValue and why encompass Maybe too?

With the newtype variant you now have to unpack two constructors to get to the value, as in:

f : Maybe ReusableDefaultValue -> a
f (Just (ReusableDefaultValue pgScalarValue)) = _
f Nothing = _

So since data types are really cheap in Haskell, we might as well re-define Maybe to get a more convenient API:

f : ReusableDefaultValue -> a
f (ReusableDefault pgScalarValue) = _
f ReusableNoDefault = _

Note that the two patterns directly give a lot of information about why we are doing pattern matching, in contrast with the newtype variant, where it's not quite clear, visually, what kind of value we are deconstructing. Indeed, in the second variant, the type signature is pretty much unnecessary to understand the code, whereas in the first variant one would need to be quite familiar with the codebase in order to be able to do without.

Anyway, this is not a critical point, so I'm happy to make this into a newtype if that allows this PR to get merged without further debate.

Let's change G.Variable to VariableInfo where VariableInfo represents (G.Variable, Maybe AnnGValue).

Currently, we seem to be adding this value here, after this change we don't need to do that anymore, validateVariables itself can build this VariableInfo and add it to the AnnInpVal.

Your link doesn't work for me, unfortunately, so I am not sure what you are suggesting.