> I suspect that you are really looking at the problem from the wrong end.
> CRC checking should not need to be done by the database user, with a fancy
> type. The postgres server itself should guarantee data integrity - you
> shouldn't have to worry about it in userland.
I agree in principle. However, performance sometimes is more important than
integrity. Think of a data logger of uncritical data. A online forum. There
a plenty of occasions where you don't have to worry for a single bit on or
off, but a lot to worry about performance. Look at all those people using M$
Access or MySQL who don't give a damn about data integrity. As opposed to
them, there will always be other "typical" database applications where 100%
integrity is paramount. Then it is nice to have a choice of CRCs, where the
database designer can choose according to his/her specific
performance/integrity balanced needs. This is why I would prefer the
"datatype" solution.
> This is, in fact, what the recent discussion on this list has been
> proposing...
AFAIK the thread for "built in" crcs referred only to CRCs in the
transaction log. This here is a different thing. CRCs in the transaction log
are crucial to proof integrity of the log, CRCs as datatype are neccessary
to proof integrity of database entries at row level. Always remember that a
psotgres data base on the harddisk can be manipulated accidentally /
maliciously without postgres even running. These are the cases where you
need row level CRCs.
Horst
