Should nextval :: QualifiedName -> Expr Int64 support more numeric types?

[raehik]

9.17. Sequence Manipulation Functions in the Postgres docs state that nextval returns a bigint, which matches with Rel8's nextval :: QualifiedName -> Expr Int64. However, the CREATE SEQUENCE page states:

The optional clause AS data_type specifies the data type of the sequence. [...] The data type determines the default minimum and maximum values of the sequence.

To me, this means the type of nextval is dependent on the sequence it's accessing. Similar to DEFAULT, that's probably not very useful for Rel8. But it is confusing: the codebase I'm poking at has many nextval functions like fooIdNextval = coerce (Rel8.nextval "foo_id_seq"). Sometimes they're coercing through both a newtype and Expr's phantom typevar at the same time. (Should Rel8 even permit coerceExpr :: Expr a -> Expr b; coerceExpr = coerce? It does. Note the lack of Coercible!)

I think this is especially relevant because the serial pseudo-type often used together with nextval corresponds to an Int32, but currently to use them together in Rel8 a user must coerce down from Int64. (I think this may have been a source of confusion in our codebase: there is a mix of Int32 and Int64 IDs that use serial in the table schema, where Int32 is surely more correct. It definitely confused me, heh.)

I don't really have an answer in mind or a specific request. (I'm also new to Rel8 and SQL in general.) Has anyone else felt this issue? Is there something I'm missing? I think a newtype PostgresSerial and a few nextval helpers would help us stay consistent, but I wonder if there's a library-level solution too.

[raehik]

bump

[raehik]

Bump. I still think there's a potential pitfall here (coerce :: Expr a -> Expr b), and a quality of life improvement to design (better nextval).

[raehik]

Bump and ping the last maintainer I had contact with @TeofilC .

[TeofilC]

We talked about this briefly at Zurihac 2026 and I said that coercing is fine or something like that and that we do similar things in the CircuitHub codebase.

But on rereading this, and further thought, I think we should make some changes to rel8.'

I agree that we shouldn't allow coercing Expr without Coercible! That seems like a straightforward bug.

I also think we should add a DBSequence typeclass that gives you nextval. It sounds like that would be more true to the design of PostgreSQL and we already have a bunch of these typeclasses.

I'll try to get around to implementing these soon, but PRs are also welcome!

[TeofilC]

This type checks coerce (lit @_ @Int64 100) :: Expr Int32 but it shouldn't! I think that's the case because GHC has determined that the Expr argument has phantom role, but it should be one of the other two

[raehik]

Probably type role Expr nominal nominal? At least, that's what Refined is defined as, which is similar in that it's a Type -> Type without a Functor instance and you can't idly change params.

[TeofilC]

#416

[TeofilC]

And here is a nicer way to do nextval which allows us to use any of {Int16,Int32,Int64} #418

[ocharles]

Ah, you are talking about actually coercing in Haskell. I thought you were talking about Coercible being evidence you could could coerce in SQL. I agree that coerce for Expr shouldn't be possible

[TeofilC]

#418 and #416 should resolve this. Feel free to re-open if not