streaming: ban double / decimal as pk

[skyzh]

Using them as PK might cause some keys not being successfully deleted.

[lmatz]

Is it considered a bug, due to ser/deser or the decimal library we use?

[skyzh]

I think it is expected. Data values like decimal / double is not closed under addition. e.g.,

1.0 + 100000000000.0 - 100000000000.0 won't produce 1.0 due to precision issues. The same applies to decimal.

I guess it would make things wrong in some places.

[lmatz]

Agree that double indeed needs to be banned, as we have no way of controlling these precision issues as long as we use the built-in double type in rust.

For decimal, I thought by its specification in PG, it is expected to be precise/exact.

My guess is that the current crate for decimal is quite limited due to its support for only 28 digits(scale? or something like that). If we would like to improve (e.g. by choosing another crate), it could be improved.

But still agree with banning it first, as decimal as part of pk should be a very rare case

[xiangjinwu]

The issue for real/float32 and double precision/float64 is that they are imprecise, making Eq and Hash less meaningful.

As for decimal (and also interval), it has another wired behavior: a == b does not mean f(a) == f(b). For example: 1.0 = 1.00 but 1.0::varchar <> 1.00::varchar. This was why we had different memcomparable encoding and value encoding.

[fuyufjh]

Regarding to being user-friendly, this should be banned on the frontend side on certain queries, such as group by any real-type column.

[github-actions]

This issue has been open for 60 days with no activity. Could you please update the status? Feel free to continue discussion or close as not planned.