> This is the kind of thing that can’t be represented in any safe language because the indication of whether a value is a pointer isn’t even in application memory.

Welcome to the wonderful world of high performance low level optimization.

Storing type ids everywhere would double the size small fields and quadruple tiny ones like booleans. It’s also not necessary for most persisted data as you know the columns for a table.

Smaller representation makes reading and writing faster, and it also makes more data fit in memory.

▲

amluto a day ago | parent [-]

Great. So you store a type id separately. But you make that typeid define how to safely read (maybe not interpret, but still read) the data without needing to cross-reference to anything else.

I’ve written plenty of high performance code. You can have safety and high performance at the same timetime.

▲

malisper 21 hours ago | parent [-]

> Great. So you store a type id separately. But you make that typeid define how to safely read (maybe not interpret, but still read) the data without needing to cross-reference to anything else.

Yes, that's how it works in Postgres

	▲	amluto 15 hours ago \| parent [-]
		Unless the OP is completely wrong, it’s not. The author was able to fairly straightforwardly prepare a statement (thus selecting a type id), execute another statement (changing the meaning of that type id), and then execute the prepared statement (uses the old type id with the new semantics, which had a different idea of whether a particular field was a pointer).